Novell® GroupWise® 7 Administrator Solutions Guide

Next Page

Book Cover
Novell® GroupWise® 7 Administrator Solutions Guide
By Tay Kratzer, Erno de Korte
...............................................
Publisher: Novell Press
Pub Date: November 02, 2005
ISBN: 0-672-32788-0
Pages: 936

Table of Contents | Index
Overview

Novell GroupWise 7 Administrator Solutions Guide is the authoritative guide for successfully administrating and maintaining the newest release of Novell's communication and collaboration solution. Author Tay Kratzer, a Novell Premium Service-Primary Support Engineer, will provide you with insider tips on administration solutions, proven information on how to work with GroupWise 7, and techniques for troubleshooting this latest release of GroupWise not available in the standard GroupWise 7 documentation. Amongst many other things, this guide will cover:

  • GroupWise Architecture

  • Using GroupWise System Operations

  • Installing and Configuring the GroupWise Internet Agent

  • Moving Resources, Distribution Lists and Libraries

  • Troubleshooting Message Flow

  • Securing your GroupWise System via SSL

  • Creating a Backup Solution for GroupWise

  • Creating a Solution to Administer a GroupWise System from a Linux Workstation

Master the management and administration of GroupWise 7 with Novell GroupWise 7 Administrator's Guide.

Next Page


Table of Contents

Previous Page
Next Page

Book Cover
Novell® GroupWise® 7 Administrator Solutions Guide
By Tay Kratzer, Erno de Korte
...............................................
Publisher: Novell Press
Pub Date: November 02, 2005
ISBN: 0-672-32788-0
Pages: 936

Table of Contents | Index

Copyright
About the Authors
Acknowledgments
 | We Want to Hear from You!
 | Reader Services
Introduction
Part I: Architecture
 | Chapter 1. GroupWise Architecture: Basics
 |  | Understanding a Basic GroupWise 7 System
 |  | Other GroupWise Objects and Services
 |  | The Evolution of GroupWise
 |  | For More Information
 |  | Summary
 | Chapter 2. Creating a GroupWise System
 |  | Installing GroupWise
 |  | Creating a GroupWise System
 |  | Creating the GroupWise Primary Domain
 |  | Summary
 | Chapter 3. Understanding the GroupWise Directory
 |  | GroupWise Directory Components
 |  | The GroupWise Domain Database
 |  | The GroupWise Post Office Database
 |  | Summary
 | Chapter 4. Understanding the GroupWise Information Store
 |  | The Post Office Directory Structure
 |  | The Core of the Messaging System
 |  | The User and Message Database Relationship
 |  | The GroupWise Document Management System
 |  | Document Reference Relationships
 |  | For More Information
 |  | Summary
Part II: Administration Interface
 | Chapter 5. Working with GroupWise Objects
 |  | The GroupWise View
 |  | Viewing the Domain Object
 |  | Viewing the Post Office Object
 |  | Configuring Library Objects
 |  | Administering User Objects
 |  | Understanding Resource Objects
 |  | The Distribution List Object
 |  | Summary
 | Chapter 6. Using GroupWise System Operations
 |  | Accessing System Operations
 |  | Changing Connections with Select Domain
 |  | System Preferences
 |  | eDirectory User Synchronization
 |  | Creating a Custom eDirectory Attribute and Using Admin-Defined Fields
 |  | Creating a Mobile Phone Entry in the GroupWise Address Book
 |  | Pending Operations
 |  | Addressing Rules
 |  | Time Zones
 |  | External System Synchronization
 |  | Software Directory Management
 |  | Using Restore Area Management
 |  | Internet Addressing
 |  | Trusted Applications
 |  | LDAP Servers
 |  | Global Signatures
 |  | Summary
 | Chapter 7. GroupWise Utilities and Diagnostics
 |  | The GroupWise Utilities Menu
 |  | Client Environment Options
 |  | Client Send Options
 |  | Understanding the Architecture Behind the Client Options Interface
 |  | Using Client Options to Lock Down the GroupWise Archive
 |  | Expired Records
 |  | Email Address Lookup
 |  | The Synchronize Tool
 |  | User Move Status
 |  | Link Configuration
 |  | Document Properties Maintenance
 |  | The New System Tool
 |  | GW/eDirectory Association
 |  | GroupWise Diagnostics
 |  | Summary
Part III: Agents and Clients
 | Chapter 8. Configuring the Post Office Agent
 |  | Loading the POA
 |  | Configuring the POA
 |  | Monitoring and Configuring the POA at the Console Screen
 |  | Understanding the Agent Log
 |  | Best Practices
 |  | Summary
 | Chapter 9. Configuring the Message Transfer Agent
 |  | Loading the MTA
 |  | Link Configuration and the MTA
 |  | Message Transfer Agent Console Commands
 |  | Notable MTA Commands and Switches
 |  | Understanding the MTA Log
 |  | Configuring the MTA to Support Live Remote
 |  | Best Practices
 |  | Monitoring Your MTA Through a Web Browser
 |  | Summary
 | Chapter 10. Installing and Configuring the GroupWise Internet Agent
 |  | GWIA Architecture
 |  | Installing the GWIA
 |  | Loading the GWIA
 |  | Understanding GWIA Configuration Files
 |  | Configuring the GWIA
 |  | Configuring Access Control
 |  | Understanding the GWIA
 |  | Understanding the GWIA Log
 |  | Configuring Dial-Up Internet Access
 |  | Monitoring the GWIA Through a Web Browser
 |  | GWIA Configuration Files
 |  | Best Practices
 |  | Summary
 | Chapter 11. Installing and Configuring GroupWise WebAccess
 |  | Understanding WebAccess Architecture
 |  | Installing the GroupWise WebAccess Gateway
 |  | Loading the GroupWise WebAccess Agent and Application
 |  | Logging In To the GroupWise WebAccess Client
 |  | Configuring the GroupWise WebAccess Gateway
 |  | Configuring the WebAccess Agent Subcomponents
 |  | Configuring the Document Viewer Agent
 |  | Understanding the GroupWise WebAccess Console
 |  | Understanding the GroupWise WebAccess Log Files
 |  | Configuring an LDAP Address Book for WebAccess
 |  | Monitoring GroupWise WebAccess Through a Web Browser
 |  | Advanced Installation Options for WebAccess
 |  | Changing the GroupWise WebAccess Login Experience
 |  | Skipping the GroupWise WebAccess Language Page
 |  | Disabling the GroupWise Document Management Options
 |  | Specifying WebAccess Client Themes
 |  | Best Practices
 |  | Summary
 | Chapter 12. Administering the GroupWise Client
 |  | Understanding the GroupWise Windows Client Installation Process
 |  | Understanding the Components That are Part of a GroupWise Installation
 |  | Introducing the GroupWise MSI installation
 |  | Installing the GroupWise Client from CD
 |  | Installing the GroupWise Client by Running SETUP.EXE from a Network Drive
 |  | Distributing the GroupWise Client via ZENworks
 |  | Creating a SETUPIP GroupWise Client Distribution System
 |  | Upgrading the GroupWise Client via a Network Drive
 |  | Adding Grace Logins Before a Forced Upgrade
 |  | Forcing a Windows Registry Change Through SETUP.CFG
 |  | Auditing the GroupWise Client Upgrade
 |  | Understanding the GroupWise Login Process
 |  | Administering the Login Process
 |  | Administering GroupWise Client Options
 |  | Comparing GroupWise Clients on Windows and Other Platforms
 |  | Summary
Part IV: Practical Administration
 | Chapter 13. Moving Users
 |  | Understanding the Directory-Level Move of a GroupWise User Object
 |  | Moving a GroupWise User
 |  | Assessing the Success of a User Move
 |  | Using the User Move Status Utility When Something Goes Wrong
 |  | Tips for Moving Many Users
 |  | Summary
 | Chapter 14. Working with GroupWise Agents on the Linux Platform
 |  | Linux Conventions
 |  | GroupWise Agent Code Installation, Configuration Files, and Agent Startup
 |  | The /etc/init.d/grpwise Script
 |  | The /etc/opt/novell/groupwise/gwha.conf File
 |  | Initializing GroupWise Agents
 |  | Locating GroupWise Agent Log Files
 |  | Summary
 | Chapter 15. Administering Multiple GroupWise Systems
 |  | Multiple-System Concepts
 |  | Releasing a Secondary Domain to Create a New GroupWise System
 |  | Synchronizing External Systems
 |  | Merging Two External GroupWise Systems
 |  | Defining IDOMAINs for an External Domain
 |  | Summary
 | Chapter 16. Internet Addressing
 |  | Overview of GroupWise Internet Addressing
 |  | Defining an Internet Address
 |  | Enabling Internet Addressing
 |  | Enabling MTA-Direct Connectivity (GWMTP)
 |  | Internet Addressing Overrides
 |  | Mail Routing with Internet Addressing Enabled
 |  | Understanding the Parsing and Lookup Process
 |  | Best Practices
 |  | Summary
 | Chapter 17. Maintaining the GroupWise System
 |  | Information-Store Maintenance Concepts
 |  | Creating Scheduled Events for Maintenance
 |  | GroupWise Archive Message Store Maintenance
 |  | GroupWise Windows Client Caching Mode and Remote Mode Maintenance
 |  | GroupWise Directory Database Maintenance
 |  | Summary
 | Chapter 18. Monitoring Your GroupWise System Through GroupWise Monitor
 |  | The GroupWise Monitor Components
 |  | Installing GroupWise Monitor Agent
 |  | Configuring Your System to Better Support GroupWise Monitor
 |  | Starting and Using the GroupWise Monitor Agent
 |  | Installing the GroupWise Monitor Application
 |  | Summary
Part V: Applied Architecture
 | Chapter 19. Building Your GroupWise System Correctly
 |  | General System Configuration
 |  | Post Office Configuration
 |  | Best Practices
 |  | Summary
 | Chapter 20. Troubleshooting Message Flow
 |  | Understanding Message Flow at the Database Level
 |  | Using File Flow for Troubleshooting
 |  | Troubleshooting Tips and Tricks
 |  | Best Practices
 |  | Summary
 | Chapter 21. Moving Domains and Post Offices
 |  | Considerations Related to Moving a Domain
 |  | Considerations Related to Moving a Post Office
 |  | Moving a GroupWise Post Office to a New UNC Path
 |  | Moving a Domain to a New OU
 |  | Summary
 | Chapter 22. Troubleshooting the GroupWise Directory
 |  | Using the Correct Tools
 |  | Fixing WPHOST.DB Files
 |  | Fixing WPDOMAIN.DB Files
 |  | Fixing GroupWise Directory Anomalies Without Rebuilds
 |  | How GroupWise Directory Changes and Objects Are Replicated
 |  | Best Practices for Working with the GroupWise Directory
 |  | Bulletproofing the GroupWise Directory
 |  | Understanding the Administration System
 |  | Summary
 | Chapter 23. Troubleshooting GroupWise
 |  | The Five Most Common GroupWise Errors
 |  | Using the Scientific Method
 |  | GroupWise Error Codes
 |  | Using Three-Step Mailbox Troubleshooting
 |  | Determining Problem Specificity
 |  | Generating a Fresh User Database Without Losing Items
 |  | Summary
 | Chapter 24. Using Wireless and Handheld Devices with GroupWise 7 WebAccess
 |  | Understanding Templates
 |  | Accessing Your GroupWise Mailbox from a Pocket PC Device
 |  | Defining a New Browser User Agent Type
 |  | Accessing Your GroupWise Mailbox from a Wireless Phone
 |  | Information Regarding SSL-ized Connections from Handheld Devices
 |  | Summary
 | Chapter 25. Configuring a Spam/Junk Mail Control Solution
 |  | Is Spam Really a Problem?
 |  | GroupWise Spam/Junk Mail Solutions
 |  | Summary
 | Chapter 26. Configuring GroupWise Authentication via LDAP
 |  | Understanding the Value of LDAP Authentication
 |  | LDAP Authentication and GroupWise External Entities
 |  | eDirectory LDAP Server Tips
 |  | Testing and Confirming LDAP Authentication
 |  | LDAP Authentication Troubleshooting Tips
 |  | Creating Fault Tolerance
 |  | Summary
 | Chapter 27. Securing Your GroupWise System via SSL
 |  | Understanding SSL Architecture
 |  | Configuring and Signing Certificates in eDirectory
 |  | Summary
 | Chapter 28. Restoring Deleted Users
 |  | The Scenario
 |  | Recover and Restore a User's Account
 |  | Import and Restore or Archive a User's Account
 |  | Bringing the User Back
 |  | Summary
 | Chapter 29. Configuring a GroupWise Messenger (Instant Messaging) System
 |  | Architectural Basics
 |  | Creating a Basic GroupWise Messenger System
 |  | Starting Your GroupWise Messenger Agents
 |  | Installing the GroupWise Messenger Client
 |  | Summary
Part VI: Solutions
 | Chapter 30. Creating a Secure Messaging Solution
 |  | So Do We Need to Fix This Problem?
 |  | Information Is Leaking Out When Email Is Sent Across the Internet
 |  | Overview of How to Secure Messages
 |  | A More Detailed Discussion of S/MIME
 |  | For More Information on Secure Messaging
 |  | Summary
 | Chapter 31. Creating a Highly Available GroupWise WebAccess Solution
 |  | High-Availability/Distributed Installation Concepts
 |  | Configuring GroupWise WebAccess for More Scalability and Stability
 |  | Summary
 | Chapter 32. Creating a Highly Available GroupWise Internet Agent Solution
 |  | The GWIA as a Connector Between SMTP and Other GroupWise Processes
 |  | DNS Services and GWIA
 |  | Using Multiple GWIAs to Strengthen the SMTP Stream for Incoming Messages
 |  | Using Multiple GWIAs for a Redundant SMTP Stream for Outgoing Messages
 |  | Summary
 | Chapter 33. Creating Solutions to Limit Post Office Message Store Size
 |  | Mailbox and Message Size Limits
 |  | Forcing Message Size Limits on the Internet Agent
 |  | Exploring Archiving Solutions
 |  | Summary
 | Chapter 34. Creating a GroupWise-to-GroupWise Communication Solution Across the Internet
 |  | An Overview of Message Transfer Protocol and Internet Addressing
 |  | Checking Whether Internet Addressing Is Enabled
 |  | Enabling MTA-Direct Connectivity (GWMTP)
 |  | Mail Routing with GWMTP Enabled
 |  | Summary
Index

Previous Page


Copyright

Novell® GroupWise® 7 Administrator Solutions Guide

Copyright © 2006 by Novell, Inc.

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.

International Standard Book Number: 0-672-32788-0

Library of Congress Catalog Card Number: 2004195541

Printed in the United States of America

First Printing: November 2005

08 07 06 05 4 3 2 1

Trademarks

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Novell Press cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Novell and GroupWise are registered trademarks; Novell Press and the Novell Press logo are trademarks of Novell, Inc. in the United States and other countries. All brand names and product names used in this book are trade names, service marks, trademarks, or registered trademarks of their respective owners.

Warning and Disclaimer

Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the CD or programs accompanying it.

Special and Bulk Sales

Pearson offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information, please contact

U.S. Corporate and Government Sales
1-800-382-3419
corpsales@pearsontechgroup.com

For sales outside of the U.S., please contact

International Sales
international@pearsoned.com

Novell Press is the exclusive publisher of trade computer technology books that have been authorized by Novell, Inc. Novell Press books are written and reviewed by the world's leading authorities on Novell and related technologies, and are edited, produced, and distributed by the Que/Sams Publishing group of Pearson Education, the worldwide leader in integrated education and computer technology publishing. For more information on Novell Press and Novell Press books, please go to www.novellpress.com.

Associate Publisher

Mark Taber

Program Manager, Novell, Inc.

Darrin Vandenbos

Marketing Manager

Doug Ingersoll

Acquisitions Editor

Jenny Watson

Development Editor

Emmett Dulaney

Managing Editor

Charlotte Clapp

Project Editor

Mandie Frank

Copy Editor

Cheri Clark

Indexer

Erika Millen

Proofreader

Lisa Wilson

Technical Editor

Erno de Korte

Publishing Coordinator

Vanessa Evans

Book Designer

Gary Adair

Page Layout

Patricia Ratcliff

Dedication

Tay Kratzer

To my wife, Irina Kratzer: Your support of all of my ventures has meant the world to me. Knowing our children are loved and so well nurtured has enabled me to do so much more than I would be able to otherwise. You are the model of the "Proper Care and Feeding of a Husband." Beside every good man is a great woman, I'm one of those very lucky men.

To my brother Lee Kratzer: Thanks for your strength and example throughout my life. Thanks for protecting your little brother and taking care of Mother.

Erno de Korte

To my two sons, Marcel and Rèmon: You two are already far ahead of all of us old people in exploring the wonderful world of gizmos, computers, and the Internet. Thanks for bringing some balance in our life by making sure your old dad was physically challenged as well during our precious sporting moments.

To my mother and father, Piet and Joke de Korte: You both have been so patient in helping me to manage the boys and keeping me on track, making sure I could do what I needed to do.

To Cor van de Merwe and Roel van Bueren, my two buddies: Thanks for staying on the same track during our long and winding journey through the wondrous world of IT for so many years. And also many thanks to all the other GroupWiseR enthusiasts, who have been so patient whenever I wasn't able to respond immediately while I was working on this book. Let's make sure much more people recognize the many strengths of GroupWise!


About the Authors

Tay Kratzer has supported GroupWise for 14 years in various capacities. At Novell he worked as a support engineer for some of Novell's larger customer sites. He is the author of several GroupWise books and articles. Tay is a Novell Master CNE, and in 2000 he was presented with the highest achievement award from the Software Support Professional Association. He is the lead practice manager for GWAVA's Linux Professional Services division. Tay also programs solutions that integrate with Novell's GroupWise.

Tay lives in Utah with his wife, Dr. Irina Kratzer, and their four children, Anastasia, Lindy, Dallin, and Wesley. He maintains a website to support this book and GroupWise topics at: www.taykratzer.com. Tay's email address is taykratzer@taykratzer.com.

Erno de Korte has been supporting GroupWise since it was called WordPerfect Office. As an MCNE and MCNI, he has been training and consulting on GroupWise throughout the world. Erno has been a speaker at many conferences and has a special interest in products that integrate with GroupWise in the areas of document management, workflow, CRM, and PDAs. He is the author of many articles for a large number of magazines, including GroupWise Advisor magazine and Novell Cool Solutions. Erno is one of the leading figures of GroupWiseR (http://www.groupwiser.com), an international initiative to combine the energy of hundreds of GroupWise enthusiasts to promote GroupWise. Erno holds a degree in technical information science from the Technical University in Delft, the Netherlands. He lives in Rotterdam, the Netherlands and is the father of two boys, Marcel and Rèmon.


Acknowledgments

Danita Zanre and Caledonia (www.caledonia.net) for contributions to the GroupWise 6.5 Administrator's book that we failed to acknowledge before. Gregg Hinchamn (a.k.a The Clustering GURU for GroupWise) man, it's been great working with you. Richard Griffith for contributions to Chapter 13. Eric Raff for contributions about monitoring GroupWise.

Thanks to the following people for their contributions to this book, and support of my knowledge of GroupWise: Howard Tayler, Ross Phillips, Ira Messenger, Matt Preston, and Wayne Lasson

Thanks to my customers who have been such a great support of me while I have written this book, and written new software solutions for GroupWise: Eva Cornish, Curtis Parker, Lisa Sato, Sarah Johnson, and Glenn Brown.

Thanks to the following people for their further support of my writing ventures: Tom West and Charles Taite

And finally thanks to the production staff for this book: Jenny Watson, Emmett Dulaney, and Mandie Frank.


We Want to Hear from You!

As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we're doing right, what we could do better, what topics you'd like to see us cover, and any other words of wisdom you're willing to pass our way.

You can email or write me directly to let me know what you did or didn't like about this bookas well as what we can do to make our books better.

Please note that I cannot help you with technical problems related to the topic of this book and that due to the high volume of mail I receive I may not be able to reply to every message.

When you write, please be sure to include this book's title and author as well as your name and email address or phone number. I will carefully review your comments and share them with the author and editors who worked on the book.

Email: | feedback@novellpress.com
Mail: | Mark Taber Associate Publisher Novell Press/Pearson Education 800 East 96th Street Indianapolis, IN 46240 USA


Reader Services

For more information about this book or others from Novell Press, visit our website at www.novellpress.com. Type the ISBN or the title of a book in the Search field to find the page you're looking for.


Introduction

Novell GroupWise is an Integrated Collaboration Environment with a rich feature set and hundreds of options. The GroupWise client runs on just about every client platform imaginable, and the GroupWise back-end components run on Linux, NetWare, and Windows server platforms. And, might we add, Novell's SUSE Linux is fun to administer! For Tay, Linux has made him feel 10 years younger and significantly enthused about his field.

In recent years GroupWise has enjoyed a significant increase in third-party vendor support. Novell's efforts to make GroupWise standards compliant have paid off, and will continue to do so in the future. Although GroupWise is somewhat new to the Linux server platform, it is already completely supported by third parties. For security, for example, there is GWAVA for Linux. For management there is Redline. And finally for hot-backup and quick-restore there is feature rich product called Reload. And there is more to come. For the customer considering GroupWise on the Linux platform, there should be no hesitation; Novell GroupWise is rock solid on the Linux platform. This book was written largely with a platform agnostic approach, however for GroupWise administrators looking for guidance on running the GroupWise Agents on Linux, read Chapter 14 of this book.

Wherever possible we have tried to write this book in a step-by-step manner. For several of the more advanced tasks you will find detailed coverage of the steps you will need to take to accomplish those tasks. Novell's online documentation department is also very good at keeping the online GroupWise documentation up-to-date.

Enjoy GroupWise 7!

Tay Kratzer and Erno de Korte


Part I: Architecture

1 GroupWise Architecture: Basics

2 Creating a GroupWise System

3 Understanding the GroupWise Directory

4 Understanding the GroupWise Information Store


Chapter 1. GroupWise Architecture: Basics

This chapter examines the Novell GroupWise architecture. It defines some terms and discusses the way some of the components interact. This chapter will prepare you for a more thorough discussion of architecture in the next chapters. It also discusses the evolution of the GroupWise product, to help you understand some of the naming conventions.


Understanding a Basic GroupWise 7 System

To truly understand GroupWise, it is imperative to have a basic knowledge of the terms used to describe it. In the following sections, the key terminology behind GroupWise is explored.

GroupWise

The word GroupWise is a Novell, Inc. trademark. It refers to a collection of applications and datastores that, taken together, provide email (and a lot more) to a community of computer users. GroupWise is properly categorized as an Integrated Collaboration Environment software, or as a "GroupWare" product.

GroupWise User

The term GroupWise user (or sometimes just user) refers to a mailbox that has been assigned to an end user on a GroupWise system. As an analogy, think of a common postal service model. A GroupWise user is similar to a P.O. box (a postal box at a traditional post office). Just as various mail items are delivered to a P.O. box, email and other items are delivered to a GroupWise user.

GroupWise Post Office

Just as a P.O. box exists at a post office, a GroupWise user exists at a GroupWise post office. A post office can also contain resources, libraries, and other GroupWise objects.

Physically, every GroupWise post office exists as a collection of directories and data files on a file server. One of the most important attributes of a post office is the path to the root of these directories, known as the UNC (Universal Naming Convention) path, as shown in Figure 1.1. Bear in mind that although you can identify all these separate files in the post office directory structure, conceptually these files behave like one large post office database, so you cannot simply replace a single file with an older file from a backup.

Figure 1.1. The details of a GroupWise post office

[View full size image]

GroupWise Domain

If GroupWise users are like P.O. boxes, and GroupWise post offices are like postal offices, the GroupWise domain is like the distribution center at the airport from which trucks shuttle mail to various post offices. At this point, the analogy gets a little difficult to follow, and domains will be discussed in terms of their functions. Domains exist to do the following:

  • Transfer items between GroupWise post offices

  • Transfer items to other GroupWise domains (which in turn deliver to their post offices)

  • Provide a point of administration for all GroupWise objects, such as users, post offices, and libraries

Although post offices see most of the action, GroupWise domains are necessary because post offices cannot be administered by themselves. Jus as you saw with post offices, every GroupWise domain has a physical location, or UNC path. This domain directory is the root of a complex directory structure containing files that are critical to the administration and proper functioning of a GroupWise system. Figure 1.2 shows the properties of a GroupWise domain, the primary domain in this instance.

Figure 1.2. The details of a GroupWise domain

[View full size image]

Primary Domain

Every GroupWise system must have a GroupWise primary domain. There can be only one primary domain in a GroupWise system. All other domains established within a GroupWise system are either secondary domains or external domains. The first domain you create in a GroupWise system must be your primary domain.

The primary domain can function like any other GroupWise domain with post offices, users, and so on. The difference is that the primary domain is the "supreme authority" within a GroupWise system. This means that any change made from any domain in a GroupWise system must be cleared through that system's primary domain. The GroupWise primary domain is responsible for replicating changes to all other domains, and in the event that a secondary domain database is damaged, the primary domain can be used to rebuild it.

There's also a thing called an IDOMAIN, or an Internet Domain. The IDOMAIN refers to the Internet domain name for your organization (for example, worldwidewidgets.com). When you create IDOMAINs in your GroupWise system, they are not synonymous with the regular GroupWise domains discussed in this chapter. IDOMAINs do not have a physical location (UNC path) associated with them as primary and secondary domains do. They are strictly used to help facilitate Internet-style addressing within a GroupWise system.

Secondary Domain

After the primary domain has been created, most GroupWise systems require secondary domains to accommodate larger numbers of users. When an administrative change is made from a secondary domain, that change must be transmitted to the primary domain before it can be replicated to the rest of the GroupWise system.

In the event that the primary domain database is damaged, a secondary domain can be used to rebuild that primary domain's database.

The GroupWise System

The GroupWise system is basically the name assigned to the collection of domains, post offices, and users (and more) that are managed from a particular primary domain. It is not a physical object with its own directory structure, or even its own object screen like domains and post offices. The icon shown in Figure 1.3 is used to represent the system.

Figure 1.3. The GroupWise system-level object

[View full size image]

Although a GroupWise system is not an object that you can physically administer, it exists so that you can define actions that will affect both the primary domain and all the secondary domains.

To understand the idea of a GroupWise system, imagine this analogy of a family. A family is not a tangible object, but an entity that defines a group of people who are related to one another. A GroupWise system is a family of GroupWise domains, with a primary domain and, usually, additional secondary domains. The administrator of a GroupWise system can make changes that affect the entire "family" of GroupWise domains (the GroupWise system). Because a GroupWise system is not an actual physical entity, all system-level records are owned by the primary domain of a system and are subsequently synchronized to every secondary domain.

GroupWise Client

The GroupWise client is an application that enables a computer user to access a GroupWise mailbox. There are four types of GroupWise clients: the Windows client, which runs on the Windows 32-bit platform (shown in Figure 1.4); the GroupWise cross-platform client (shown in Figure 1.5); the GroupWise WebAccess client (shown in Figure 1.6); and GroupWise Wireless clients, which can run on various browser platforms. The GroupWise Windows client and cross-platform client typically talk directly to a Post Office Agent (POA) in order to access the mailbox; the WebAccess and Wireless clients access the POA via a special WebAccess agent.

Figure 1.4. The GroupWise 7 Windows client interface

[View full size image]

Figure 1.5. The GroupWise 7 cross-platform client for Linux and Macintosh

[View full size image]

Figure 1.6. The GroupWise 7 WebAccess client

[View full size image]

POA

Every GroupWise post office must have a Post Office Agent associated with it that updates user mailboxes on that post office. A POA is a software process that typically runs on the same file server that houses the GroupWise post office. It also updates its GroupWise post office with administrative changes made from a domain in the GroupWise system; these might be address book changes or changes relevant to end users' interaction with the GroupWise system (such as rights to libraries or membership in distribution lists). The POA is discussed in more detail in Chapter 8, "Configuring the Post Office Agent." Figure 1.7 shows a GroupWise POA object.

Figure 1.7. A GroupWise POA object

[View full size image]

MTA

Every GroupWise domain must have a message transfer agent (MTA) associated with it. The MTA services the domain and each of the entities (post offices or gateways) associated with that domain. It is a software process that typically runs on the same file server that houses the GroupWise domain.

The MTA is the agent that transfers messages between the post offices and the gateways owned by the domain. It also transmits and receives messages with other domains on the GroupWise systemor even with domains outside of your GroupWise system, if you let it. The MTA does not deliver messages to user mailboxes, but drops messages off to the POA at a post office. The POA then delivers to the user mailbox databases. Figure 1.8 shows a GroupWise MTA object.

Figure 1.8. The GroupWise MTA object

[View full size image]

GroupWise Administrator

The GroupWise Administrator application is a collection of snap-in modules for ConsoleOne. A GroupWise system must include at least one server with Novell eDirectory. GroupWise uses eDirectory for a portion of its administrative directory. Figure 1.9 shows GroupWise Administration and the several GroupWise objects that can be configured for GroupWise.

Figure 1.9. The GroupWise view in ConsoleOne

[View full size image]

The GroupWise Directory

The GroupWise directory is the collection of databases that define the GroupWise system's domains, post offices, users, and other objects. The GroupWise directory has two major components:

  • eDirectory

  • GroupWise domain and post office databases

eDirectory

Novell eDirectory is the leading cross-platform network directory solution. eDirectory is commonly used to define user accounts on file servers across enterprise networks, and it provides for simple, centralized administration.

eDirectory provides GroupWise administrators with the capability to manage their users' GroupWise mailboxes and network accounts from the same interface, ConsoleOne.

GroupWise Domain and Post Office Databases

The largest portion of the GroupWise directory is in the GroupWise domain and post office databases. These database files are named WPDOMAIN.DB and WPHOST.DB. Every domain has a WPDOMAIN.DB file, which is that domain's database. Every post office has a WPHOST.DB file, which is that post office's database.

When ConsoleOne is loaded with the GroupWise Administrator snap-ins, ConsoleOne can be used to update both the eDirectory and the WPDOMAIN.DB file. When a GroupWise domain's MTA is loaded, it must be pointed at the domain's WPDOMAIN.DB file. The WPDOMAIN.DB is the brain of the MTA and instructs the MTA how to route messages.

Every post office POA must have the path to the WPHOST.DB database in order to load. The WPHOST.DB database is often referred to as the address book. This is the database GroupWise clients read in order to see other users and objects in their GroupWise system.

The GroupWise Message Store

A GroupWise message store is contained at each GroupWise post office. This is where a user's mailbox, with all its attendant messages and other data, is contained. The message store is the heart of what users interact with while they are running the GroupWise client. Physically these files are stored in the OFUSER, OFMSG, and OFFILES directories of the post office directory structure.

A GroupWise message store can also exist in the form of a GroupWise "caching" mode mailbox, in remote email, or in a GroupWise archive mailbox. Chapter 4, "Understanding the GroupWise Information Store," discusses the message store in much more detail.

GroupWise Messenger

The GroupWise Messenger Instant Messaging solution is a separate collaboration solution, independent of GroupWise and only loosely integrated. Chapter 29, "Configuring a GroupWise Messenger (Instant Messaging) System," focuses on how to configure a GroupWise Messenger solution.


Other GroupWise Objects and Services

This chapter has discussed users, post offices, domains, and systems, and it has also touched on the agents and the directory. The discussion of the basic GroupWise architecture is complete, but there are several types of GroupWise objects that have not been discussed. Subsequent chapters will also discuss the following:

  • Gateways

  • Libraries

  • Resources

  • Distribution lists

  • Nicknames


The Evolution of GroupWise

GroupWise 7 is a seventh-generation product. The original ancestor of GroupWise 7 was called WordPerfect Office 1.0. When Novell bought WordPerfect Corporation, and later sold it to Corel, Novell retained the GroupWise product line. Prior to GroupWise 7, there were seven revisions of GroupWise that are of interest in this book: GroupWise 4.1, GroupWise 5.0, GroupWise 5.2, GroupWise 5.5, GroupWise 5.5 Enhancement Pack, GroupWise 6, and GroupWise 6.5.

It's helpful to understand that GroupWise evolved from WordPerfect Office, because the current product retains some of the earlier naming conventions for files and directories. Anywhere you see WP or OF, you are looking at the legacy of WordPerfect Office:

  • WP: The GroupWise domain database is called WPDOMAIN.DB. You will also find WPHOST.DB, WPGATE, WPCSIN, and WPCSOUT.

  • OF: All GroupWise post offices have directories called OFUSER, OFFILES, and OFMSG.

The reason Novell retained the WordPerfect and Office naming conventions was to provide backward compatibility with older versions of GroupWise and WordPerfect Office. As new components have been added to GroupWise, the names of these components have followed the new GroupWise or Novell GroupWise names. For example:

  • GW: The name of a GroupWise domain dictionary file is GWDOM.DC. Look for GW in the names of GroupWise NetWare loadable modules too.

  • NGW: Every GroupWise post office has an important file called NGWGUARD.DB.


For More Information

The GroupWise online documentation discusses the components of a GroupWise system. Have a look at the Administration section of this documentation found at www.novell.com/documentation.


Summary

A GroupWise system is a combination of logical and physical components that work in harmony with one another:

  • GroupWise Administrator: The snap-in software in conjunction with ConsoleOne.

  • The GroupWise Directory: The combination of GroupWise domains and post offices, and Novell eDirectory.

  • The Message Transfer System: The GroupWise MTA and POA.

  • The GroupWise Message Store: The collection of files and directories in a GroupWise post office that contains all the mail messages and other items in user mailboxes.

  • The GroupWise Client: Your end users' tools for reading mail, sending new mail, and collaborating with each other.

Chapter 2, "Creating a GroupWise System," Chapter 3, "Understanding the GroupWise Directory," and Chapter 4, "Understanding the GroupWise Information Store," will expose you to each of these components from an architectural standpoint.


Chapter 2. Creating a GroupWise System

This chapter traces the creation of a GroupWise system. The goal is to explore the architecture in a way that will better help you understand it. Some aspects of GroupWise architecture are easier to explain as a GroupWise system evolves; these aspects are explored in later chapters.

For the purposes of this chapter, GroupWise 7 is going to be installed at the fictional WorldWide Widgets Corporation. This fictional company is used for many examples throughout the book.


Installing GroupWise

WorldWide Widgets has a mixture of Novell NetWare 6.5, Open Enterprise Server (Linux Kernel), and Windows 200x servers in its network. The company also has met one of the most important criteria for installing GroupWise, which is that its network supports Novell eDirectory. To install GroupWise, follow the steps in the following sections.

Creating the Master GroupWise 7 Software Distribution Directory

The GroupWise CDs should be copied onto a network drive. This way you can easily apply patches and make configuration changes to files as needed. The steps to do this are as listed here:

1. | Insert the GroupWise 7 Administration CD.
2. | Close the GroupWise 7 install screen if it appears (it will not appear if autorun is not enabled on your PC).
3. | Create a location for a new GroupWise 7 Software Distribution Directory (SDD). Do not try to overwrite an existing GroupWise Software Distribution Directory. For example, you might create F:\GW70SDD as your new SDD. Or on a Linux server you could create /gw70sdd as the GroupWise 7 Software Distribution Directory.
4. | Copy the entire GroupWise 7 Administration CD contents to the GroupWise 7 SDD location that you created in step 3.
5. | If the SDD is copied to a NetWare or a Windows server, remove the read-only property from the GroupWise 7 SDD. To do so in Windows Explorer, highlight the GroupWise 7 SDD (GW70SDD in our example) and select File, Properties. Remove the check mark next to the read-only attribute. When you click OK, you will be asked how much further to apply this attributeapply the change to the folder, subfolders, and all files.

You are now ready to actually install GroupWise on your network.

Extending the eDirectory/NDS Schema and Install Administration for GroupWise 7

In this section you will add new attributes to existing eDirectory objects, such as user objects, and you will add definitions to eDirectory for new object types. This is called extending the eDirectory schema.

Novell eDirectory comes with a basic set of definitions for objects and their attributes. When GroupWise extends the schema of eDirectory, it adds new definitions, allowing eDirectory to contain new objects and new attributes for existing eDirectory objects. [Novell GroupWise (NGW): Post Office] is a new object type that the GroupWise schema extension defines. The [NGW: Object ID] is a new, GroupWise-specific attribute that is added to the existing eDirectory user class object.

The eDirectory schema definitions are added to eDirectory via standard developer APIs. You can find the GroupWise schema definition information in an ASCII file in the ADMIN folder of the GroupWise 7 CD. The name of the file is gwschema.sch.

If you do not have administrative rights to the root of your eDirectory tree, another administrative user can perform the steps in this section for you. You cannot proceed until the schema has been extended.

Installing on NetWare

The following steps enable you to install the GroupWise Administration software. These are the steps for the NetWare/Windows platform (the steps for a Linux platform are given later):

1.
You must be logged into your Novell eDirectory tree as a user with administrative rights to the tree in order to extend the schema of the eDirectory tree. Supervisor rights are required at the [Root] of the eDirectory tree in order to extend the tree schema. Your workstation should preferably be connected to a server with a replica of the root of the eDirectory to improve the speed of the installation process.

2.
If you have ConsoleOne installed on your computer, run ConsoleOne and choose Help, About ConsoleOne to determine the version of ConsoleOne you are running. The version of ConsoleOne that comes with the first shipping version of GroupWise 7 is version 1.3.6. If the version of ConsoleOne you are running is older than 1.3.6, you must install the ConsoleOne version that comes with GroupWise 7. The process to do so is explained in step 6.

3.
Go to the GroupWise 7 SDD\ADMIN directory and run INSTALL.EXE.

4.
Proceed to the Administration Options screen, uncheck the option Create a New System or Update an Existing System and the option Copy Files to a Software Distribution Directory (as shown in Figure 2.1), and then click Next. You do not want to use these options because you already copied the complete software set manually, and in this case you don't want to create a new system automatically.

Figure 2.1. The GroupWise 7 administration installation screen

[View full size image]

5.
Select the eDirectory tree in which you intend to create your GroupWise system. Click Next and proceed to Extend the Schema of Your eDirectory Tree.

6.
Now you need to install ConsoleOne to the GroupWise administrator's computer. Assuming you left the Install Administration Files check box checked as instructed earlier, you should now be at the Select Languages screen. Check the languages you want to install for the administration files. Click Next.

Note

If you have ConsoleOne and it is newer than ConsoleOne version 1.3.6, which is the version required to work with GroupWise 7, skip step 7. Do not install ConsoleOne; just install the GroupWise 7 Snap-ins to ConsoleOne.

7.
(You might already have ConsoleOne 1.3.6 installed. If you do, you do not need to reinstall it.) You will now be at the ConsoleOne Path screen. Verify that this is the path where you want to install ConsoleOne. Click the Install ConsoleOne button. A Java installation routine will be launched. Proceed through the ConsoleOne installation. Even though the ConsoleOne version you are installing is 1.3.6, it defaults to an install path of C:\Novell\ConsoleOne\1.2; this does not affect the version of ConsoleOne.

8.
After ConsoleOne has been installed (or if ConsoleOne is already installed and you are skipping step 7), you will be returned to the ConsoleOne Path screen. Verify that the path to ConsoleOne is correctly indicated, and then click the Next button.

9.
At the Ready to Install screen, click Install to begin the GroupWise 7 ConsoleOne Snap-in installation.

Installing on Linux

The following steps enable you to install the GroupWise Administration software on the Linux platform:

1. | Install ConsoleOne 1.3.6 (or later) for Linux. ConsoleOne for Linux does not come on the GroupWise CD. You can obtain ConsoleOne for Linux from http://download.novell.com.
2. | Go to the GroupWise 7 SDD and run this: ./install.
3. | Select Install Products.
4. | Select GroupWise Administration.
5. | Select Install Administration.
6. | Launch ConsoleOne for Linux, and authenticate in ConsoleOne to the eDirectory tree in which you intend to create your GroupWise system. To do this, select File, Authenticate.

The following section establishes a new GroupWise system.


Creating a GroupWise System

To create a GroupWise system, you must launch ConsoleOne. To create the GroupWise system and GroupWise primary domain for WorldWide Widgets Corporation, the administrator chooses Tools, GroupWise Utilities, New System.

Note

On Linux you're not logged in to eDirectory; therefore, after opening ConsoleOne, you first need to log in to the eDirectory before you can create your GroupWise system.

There is a set of prompts that asks the administrator for information regarding the creation of a GroupWise system. The following sections take a close look at the prompts that are relevant to understanding GroupWise architecture.

Selecting the Software Distribution Directory

Fill in the Software Distribution Directory prompt, shown in Figure 2.2, with the path where you installed the GroupWise software (earlier in this chapter, you copied the GroupWise 7 CD manually to a directory on a file server). The location where you copied the GroupWise 7 CD is the location you should select for the Software Distribution Directory. For example, gw70sdd is shown in Figure 2.2.

Figure 2.2. Prompting for the Software Distribution Directory

[View full size image]

Selecting an eDirectory Tree

You can create GroupWise only in an eDirectory tree that has had its schema extended with the GroupWise schema extensions, as explained earlier. You will be prompted for an eDirectory tree to install GroupWise to, as shown in Figure 2.3. Select the eDirectory tree that you extended the schema for earlier in this chapter.

Figure 2.3. Prompting for the eDirectory tree

[View full size image]

Choosing a System Name

Now you need to decide on a name for your GroupWise system (see Figure 2.4). The GroupWise system name is rarely referenced again, but it will always be visible in the GroupWise system view in ConsoleOne. If WorldWide Widgets ever wants to enable a feature called external system synchronization, it has to share its GroupWise system name with its partner. Chapter 6, "Using GroupWise System Operations," talks more about external system synchronization.

Figure 2.4. Prompting for the system name

[View full size image]


Creating the GroupWise Primary Domain

The primary domain is the first thing that actually denotes the physical creation of a GroupWise system. The primary domain serves as the following:

  • The "master" of the GroupWise system

  • An object in eDirectory

  • A set of files and directories/folders needed for any GroupWise domain, physically located at a specific UNC path on a file server

Because the primary domain must serve all of these functions, it is important that you carefully plan for it.

Choosing Your Primary Domain Name

Choose domain names carefully, because you cannot change them after you've created them. Figure 2.5 shows the prompt for the primary domain name. We suggest using naming conventions that adhere closely to those used in your eDirectory tree and server environment. WorldWide Widgets will call its primary domain CORP. Don't use any of the following invalid characters when naming the domain:

  • ASCII characters 013

  • The "at" sign @

  • Braces {}

  • Parentheses ()

  • A colon :

  • A comma ,

  • A period .

  • A space

  • A double quote "

Figure 2.5. Naming a primary domain

Tip

If possible, keep domain and post office names equal to or shorter than eight characters in length. This makes it easy to have directory names that match the name of the domain and helps avoid confusion. Also, with the (possible) introduction of Linux, avoid using uppercase in any of your directory names.

Selecting a Primary Domain Directory

This is where the primary domain will physically reside. This directory must be on a file server. It need not be on a NetWare server, though; it can also be on a Linux or Windows server. Specify a path that is no longer than eight characters in length. The path should not contain spaces or periods and should be made up of only letters, numbers, and dashes or underscores. For domains on the Linux platform, make certain that the name for the directory is indicated in lowercase. Do not create a domain directory in uppercase, because the Linux GroupWise Message Transfer Agent does not like uppercase directory names.

Warning

Never give your users file access to a domain directory. They don't need it, and if they arbitrarily delete files, you might be in a world of hurt.

Specifying the Domain Context

This is where you place the GroupWise primary domain object in your eDirectory tree. The domain context is important only from an administration standpoint. If your company implements security controls on eDirectory objects, for example, you might want to have a container for GroupWise objects. You might want to use organizational role objects to administer trustee assignments to the GroupWise system. In this way, you can control which of the system administrators can perform GroupWise administration operations.

WorldWide Widgets has decided to make its GroupWise domain structure match its eDirectory Organization Unit structure. In large systems, in which operators all over the network are making changes in eDirectory, creating a GroupWise OU helps non-GroupWise administration personnel understand the separate purpose of the GroupWise objects. As shown in Figure 2.6, you will be prompted for the eDirectory OU to place the primary domain object into.

Figure 2.6. Primary domain eDirectory context

Note

If you need to move a GroupWise domain or post office to a new eDirectory container, refer to Chapter 21, "Moving Domains and Post Offices."

Letting GroupWise Know Your Time Zone

By specifying which time zone a GroupWise post office or domain is in, you affect how appointment and status message timestamps are created. Be sure to specify the correct time zone information or people will miss appointments. The time zone for the primary domain will be the time zone for the location where the file server is that will house the GroupWise primary domain. Be aware that for many reasons a GroupWise environment maintains its own daylight saving time (DST) scheme, independent of the underlying server which might change to DST on other dates. Chapter 6 covers time zone administration in more detail.

Giving the Post Office a Name

Although you might not want to create a post office yet, the installation wizard requires you to do so. The name of a post office cannot be changed, so choose wisely!

It is also possible that you have no intention to keep the post office that the wizard requires you to create. If that is the case, no particular care needs to be taken in creating the post office. After the wizard is complete, you will just delete the post office.

Giving the Post Office a Home: The Post Office Directory

The post office directory is the physical location for the GroupWise post office. A GroupWise post office is a set of files and a directory structure. All GroupWise post offices have the same kind of structure. Specify a path that is no longer than eight characters in length. The path should not contain spaces or periods but should be made up only of letters, numbers, and dashes or underscores. For post offices on the Linux platform, make certain that the name for the directory is indicated in lowercase. Do not create a post office directory in uppercase, because the Linux GroupWise Post Office Agent does not like uppercase directory names.

The post office contextis where the post office object will be placed in your eDirectory tree. This context is important to your users, for reasons explained further in Chapter 12, "Administering the GroupWise Client." The GroupWise client can use eDirectory to authenticate users to their mailboxes; having the post office in the same context as your users speeds up authentication. If you place post offices in contexts where users have no trustee assignments, you will create administration headaches for yourselflater.

Note

There is no security risk inherent in allowing users to have browse, read, and compare rights to post office objects in the eDirectory tree.

Defining a Post Office Link

Each post office communicates with the rest of the GroupWise system through the domain's MTA. For the MTA to "talk" with a post office, it needs a way to hand messages to the post office. An MTA can either drop off and pick up files at the post office via a UNC connection, or transmit files via TCP/IP to the POA servicing the post office. Figure 2.7 shows the post office link prompt. A UNC link is called a direct link in this screen. A TCP/IP link is just as direct, however, and almost always preferred. These are the choices available:

  • Direct Link: This older method of linking a domain to a post office requires that the MTA have file system rights to the UNC path where the post office is. A direct link is sometimes used, particularly if your GroupWise post office is on the same file server that houses the domain that owns the post office. In most cases, even if a domain and a post office are on the same file server, it is better to configure a TCP/IP connection between the MTA and the POA. The Linux MTA does not support a direct link type; only a TCP/IP link is supported.

  • TCP/IP Link: This is the preferred method for linking the domain's MTA with a post office's POA and the only method available for a Linux environment.

Figure 2.7. Post office link

Selecting Post Office Users

You can select users to be associated with this post office at this point. You also can do this later as you create additional users.

Tip

One advantage to not selecting users for the post office yet is that GroupWise enables you to set a system-wide default password. By not selecting users to add to the GroupWise system at this point, you can set up this default password feature and then add the users to the GroupWise system. You'll learn more about setting a default system password in Chapter 6.


Summary

This chapter walked you through the creation of a GroupWise system. This chapter also discussed creating a GroupWise system, domain, and post office. You should now be fairly secure in your understanding of the general architecture of a GroupWise system. The next chapter explores the GroupWise directory in greater detail.


Chapter 3. Understanding the GroupWise Directory

This chapter explores how the various components of the GroupWise directory fit together. It examines some principles of administration and the flow of administrative messages through the GroupWise system, and it lays the groundwork for a very detailed discussion on troubleshooting and fixing the GroupWise directory found in Chapter 22, "Troubleshooting the GroupWise Directory." The term GroupWise directory refers to the databases used to manage GroupWise objects.


GroupWise Directory Components

As mentioned in earlier chapters, the GroupWise directory uses both eDirectory and the GroupWise domain and post office databases. eDirectory and the GroupWise domain database (WPDOMAIN.DB) together provide the administration-level directory databases. The portion of the GroupWise directory that is replicated for GroupWise clients to use is the post office database (WPHOST.DB).

GroupWise domain, post office, and message store databases use an underlying architecture called FLAIM, which allows for billions of extensible records. Until 1999, eDirectory used a different architecture that was also extensible, but did not work as well for large numbers of records. In 1999, Novell released eDirectory version 8, which also uses FLAIM as its underlying architecture. Despite the fact that the underlying FLAIM technology is now similar, the two systems are still separate.

Figure 3.1 shows some important architectural concepts that need to be explored:

  • When GroupWise objects are administered, most of the information goes into the GroupWise FLAIM databases.

  • Information in eDirectory is moderately important to GroupWise administration.

  • Every GroupWise domain database is essentially identical to every other record in the other GroupWise domain databases.

  • GroupWise post office databases accept only information that has first flowed through their owning domain.

  • Not all information written to a domain database is written to a GroupWise post office database.

  • GroupWise post office databases are not directly modified by GroupWise administration.

Figure 3.1. The GroupWise directory databases

How eDirectory Is Used

It is important to understand that GroupWise evolved from WordPerfect Office. Before a heavy-duty, industry-recognized directory such as eDirectory came along, many applications had to have their own directory. With the release of GroupWise 5x, Novell began the process of merging the GroupWise directory with eDirectory. GroupWise administration requires eDirectory, but the primary domain database is still the ultimate authority in a GroupWise system.

Channeling GroupWise administration through eDirectory gives GroupWise administration two major improvements over versions that did not support eDirectory/Novell Directory Services (NDS) (and over many other applications that do not leverage eDirectory):

  • Authentication security: In older versions of GroupWise, if users could get into GroupWise administration, they could exert control over any object. Now, access to individual GroupWise objects and their properties can be controlled through eDirectory.

  • Single point of administration: Most GroupWise customers have already implemented an eDirectory tree. Having GroupWise mailboxes associated with their eDirectory user objects makes administration much easier. A phone number change or a name change needs to be done only once.

Grafting GroupWise Objects with eDirectory

The process of connecting GroupWise objects to their eDirectory equivalents is referred to as grafting. There are menu options in GroupWise administration that enable administrators to graft a domain, post office, or user into the eDirectory tree. The term graft might build a mental image in which a branch is taken from one tree and put on another tree.

Grafting GroupWise objects creates new objects in eDirectory, but those objects are fully contained in the WPDOMAIN.DB file. Most GroupWise objects in an eDirectory tree should be regarded as aliases, or pointers, to the actual object in the GroupWise FLAIM databases. Grafting objects into eDirectory allows objects to then be controlled through eDirectory.

The GroupWise directory is largely contained in GroupWise FLAIM databases. GroupWise FLAIM databases have their own repair and analysis tools, which are discussed in Chapter 17, "Maintaining the GroupWise System," and Chapter 22, "Troubleshooting the GroupWise Directory." Rarely is a GroupWise directory problem fixed by running the eDirectory repair tool, DSREPAIR.


The GroupWise Domain Database

A GroupWise domain directory contains a critical file, WPDOMAIN.DB, as shown in Figure 3.2. This is the domain database.

Figure 3.2. A GroupWise WPDOMAIN.DB file in a domain directory

Creating the First WPDOMAIN.DB File (the Primary Domain)

When a GroupWise system is created, a WPDOMAIN.DB file for the primary domain is created based on the following:

  • Information that the administrator inputs

  • Information from eDirectory

  • Information from the domain structure, or dictionary file, called GWDOM.DC

The GWDOM.DC file is located at the root of any domain's directory. The GWDOM.DC file is an ASCII text file that defines the structure for all GroupWise 7 domain databases. The GWDOM.DC file should never be edited or modified.

Creating Secondary Domains

When a GroupWise secondary domain is originally created, it is created from information in the WPDOMAIN.DB file from the primary domain and the generic GWDOM.DC file. The information in a GroupWise secondary domain is an exact duplicate of the information in the primary domain. The only thing that makes the primary domain "primary" is that the Domain Type field, shown in Figure 3.3, reads as Primary.

Figure 3.3. The domain type for the primary domain

[View full size image]

A secondary domain's Domain Type field, shown in Figure 3.4, reads as Secondary.

Figure 3.4. The domain type for a secondary domain

[View full size image]

How a WPDOMAIN.DB File Changes and Increases in Size

As new objects and users are added to a GroupWise system, those objects are replicated to every WPDOMAIN.DB file in a GroupWise system. Deletions and changes of objects are also replicated to every WPDOMAIN.DB file in a GroupWise system. The only two entities that write to a WPDOMAIN.DB file are the following:

  • GroupWise administration snap-ins in ConsoleOne

  • The admin thread of the GroupWise MTA

Suppose a GroupWise directory update message is sent from the CORP domain to the MFG domain. The administrator who makes the change is connected to the CORP domain, so GroupWise administration snap-ins write the changes to WPDOMAIN.DB for CORP. The CORP MTA sends the update to MFG. Now the MFG domain's MTA will be responsible for updating the MFG domain database (WPDOMAIN.DB) file.

The Role of Domain Databases and Information Replication

Ideally, each GroupWise domain database has a record for every object in the GroupWise system. When a GroupWise domain adds an object, it transmits a copy of that object to the primary domain, to be replicated to all other domains. Larger GroupWise systems are in a constant state of change. A change to a GroupWise object should take a short while to replicate to all other domains, but on a large system, "a short while" might mean 15 minutes or more.

This means that if for some reason one of your domain databases is damaged, you should recover it from tape backup or rebuild it, which is always done from the primary domain's database. Recovering a domain database from a backup tape that is more than a day old can result in serious synchronization problems with the other domains.

Understanding the Directory Role of the Domain Database

The administration role of the WPDOMAIN.DB is to contain GroupWise objects in a database. With the help of GroupWise administration snap-ins, GroupWise objects in the WPDOMAIN.DB file can be created and modified. Whenever you administer your GroupWise system, GroupWise administration is connected to any one of the WPDOMAIN.DB files in your system. One WPDOMAIN.DB file exists for each domain. GroupWise administration enables you to connect to any one of your domains.

The GroupWise directory is a fully replicated directory. This means the following:

  • Every object that primary DOMAINA has ownership of is replicated to the secondary DOMAINB and DOMAINC.

  • Every object that DOMAINB has ownership of is replicated to the primary domain DOMAINA and consequently to the secondary DOMAINC.

  • Every object that DOMAINC has ownership of is replicated to the primary DOMAINA and consequently to the secondary DOMAINB.

If GroupWise administration is connected to DOMAINA, you can still modify almost all the objects that DOMAINB owns (as long as you have the eDirectory rights to that object). This process is explained in the following section, "Understanding Object Ownership." For those familiar with eDirectory, this object modification model might seem different. The GroupWise replication model is different from eDirectory in these two ways:

  • eDirectory uses a partitioned architecture. Although a server might contain eDirectory databases, the objects in those databases do not necessarily represent all the objects in an eDirectory tree.

  • eDirectory requires that only servers with replicas of a particular partition be allowed to accept changes to the objects.

The primary reason the GroupWise replication model is different from eDirectory is that the GroupWise directory is not extensible, and will never grow to the size of an eDirectory tree.

Understanding Object Ownership

Every user must be associated with a post office. Every GroupWise post office must be associated with a GroupWise domain. Consider the following scenario:

DOMAINA owns a post office called POST1, and POST1 has Eva Cornish associated with it. In this scenario, the following information can be extrapolated:

  • DOMAINA owns POST1.

  • Eva Cornish is associated with POST1.

  • DOMAINA must own the object Eva Cornish.

Ownership is an important role because it plays a key part in ensuring that an object or a record is properly synchronized across all domain databases (WPDOMAIN.DB files).

There are some objects that are considered system records. System records are actually owned by the primary domain. Some examples of system records are Software Distribution Directories, Internet Domain definitions, and Restore Areas.

How GroupWise Objects Stay Synchronized

Only the GroupWise domain that owns a particular object or record can officially approve a change to an object. Another domain might propose a change to an object or a record, but that proposal must be approved by the object's owning domain. Here's an example in which the whole process of GroupWise directory changes is drawn out.

Consider the following scenario: Secondary DOMAINB owns Eva Cornish. The GroupWise administration snap-ins for ConsoleOne are connected to secondary DOMAINC (a domain that does not own the object being modified) and change the phone number for Eva Cornish:

  • DOMAINC: Secondary domain

    • Eva Cornish's phone number is changed.

    • The record for Eva Cornish in DOMAINC's WPDOMAIN.DB file is changed from safe to modify.

    • The proposed change is sent to DOMAINB by DOMAINC's MTA.

    • The administrator can view the proposed change while connected to DOMAINC by selecting Tools, GroupWise System Operations, Pending Operations.

  • DOMAINB: Secondary domain

    • DOMAINB's MTA receives the change information from DOMAINC and accepts the change. It changes the user object's phone number in its WPDOMAIN.DB.

    • DOMAINB increments the record version of this object from version 1 (version 1 was initial creation) to version 2. The fact that the record version value increments to 2 is not propagated to other domains.

    • DOMAINB's MTA creates a message destined to the primary domain telling the primary domain about the change to the object Eva Cornish.

    • DOMAINB's MTA creates a message destined for the post offices that it owns, indicating the change to the object Eva Cornish.

  • DOMAINA: Primary domain

    • DOMAINA's MTA receives from DOMAINB the change to object Eva Cornish to its WPDOMAIN.DB file.

    • DOMAINA's MTA creates a message and sends this message to all other domains (except DOMAINB), telling all other domains to rewrite this entire user object record with the information that the primary domain is sending about this object record.

    • DOMAINA's MTA creates a message and sends this message to each of its own post offices indicating the change to Eva Cornish.

  • DOMAINC: Secondary domain

    • DOMAINC's MTA receives from DOMAINA the change to object Eva Cornish to its WPDOMAIN.DB file.

    • DOMAINC changes the record on object Eva Cornish from modify to safe.

    • DOMAINC sends a message to each of its own post offices indicating the change to the object Eva Cornish.

  • All other secondary domains

    • DOMAINX's MTA receives from DOMAINA the change to object Eva Cornish to its WPDOMAIN.DB file.

    • DOMAINX's MTA sends a message to each of its own post offices indicating the change to object Eva Cornish.

From the preceding synchronization detail, the following conclusions can be drawn about how objects are synchronized to the GroupWise directory:

  • If an administrator has eDirectory rights to do so, he or she can be connected to any domain in the system and modify objects associated with another domain.

  • The only domain that can approve an object change is the domain that owns the object.

  • The only domain that can propagate object changes to an entire GroupWise system is the GroupWise primary domain.

  • Each domain is responsible for propagating directory changes to the post offices that it owns.

Knowing the Agent Information Role of the Domain Database

When a GroupWise MTA loads, it must point to the root of the domain directory, which contains the WPDOMAIN.DB file. The WPDOMAIN.DB file provides three basic types of information to the MTA:

  • Configuration information: When to connect, how many threads to load, and so on.

  • Link information: How to establish a connection with the other domains on the system.

  • Routing information: Discovering the correct route to use to send messages to their destinations.

The MTA specifically reads the MTA object record associated with the domain that the MTA points to. Under Tools, GroupWise Diagnostics, Record Enumerations, this record is found in the Message Transfer Agents by Domain section.

The other processes that access the WPDOMAIN.DB file directly are the GroupWise Internet Agent (GWIA), the WebAccess Agent, and the various GroupWise gateways. They all need the same basic kind of information:

  • Configuration information: When to connect, how many threads to load, and so on.

  • Addressing information: Looking up users to deliver inbound mail to them.


The GroupWise Post Office Database

Every GroupWise post office must have a WPHOST.DB file. The WPHOST.DB file for a post office provides the following:

  • The GroupWise client address book

  • Lots of information for the GroupWise client and Post Office Agent (POA) that isn't readily apparent to a user

A GroupWise WPHOST.DB file is created when a post office is created. The WPHOST.DB file is created using the following:

  • Information from the WPDOMAIN.DB file of the GroupWise domain that owns the post office

  • The dictionary file called GWPO.DC located in all GroupWise domain and post office directories

These topics are explored further in the following sections.

How a WPHOST.DB File Is Modified

When a change needs to be replicated down to a post office, the domain MTA for the domain that owns the post office needing the replication sends the object update information to the POA servicing the post office. The POA has an admin thread that updates the WPHOST.DB file with the change.

The only entity that updates a WPHOST.DB file is the GroupWise POA. This is different from how a WPDOMAIN.DB file is modified. The WPDOMAIN.DB file is modified by the GroupWise MTA and by GroupWise administration. So when an administrator makes changes that affect GroupWise, those changes are written to the WPDOMAIN.DB that the GroupWise administration is connected to. The administrator's workstation actually commits those changes to the GroupWise WPDOMAIN.DB. In the case of post offices, an administrator's workstation does not touch the WPHOST.DB file. The only time an administrator's workstation would touch a WPHOST.DB file is when the administrator uses Tools, GroupWise Utilities, System Maintenance to run routines on a post office.

The Content of a WPHOST.DB File

A WPHOST.DB file is not a mirror of the entire GroupWise system. There are records related to domains that do not need to be replicated to a WPHOST.DB file. Because the WPHOST.DB file is not a general depository file like the WPDOMAIN.DB file, the content of a WPHOST.DB file is smaller than that of a WPDOMAIN.DB file.

WPHOST.DB as an Address Book

When users go into the GroupWise address book and access the Novell GroupWise address book (otherwise known as the system address book), they are accessing information contained in the WPHOST.DB file. The information accessible in any of the other tabs of the GroupWise address book is not contained in the WPHOST.DB file.

WPHOST.DB for Identity Purposes

The WPHOST.DB file is read by the GroupWise client in order to help the GroupWise client create an appropriate environment for the users. The WPHOST.DB file helps the client and the POA identify which USERXXX.DB file in the message store is the user's database. The WPHOST.DB file helps to hold administrator-defined settings that control how GroupWise preferences are configured. A WPHOST.DB file has a hidden password within it; that password is given to all databases below a post office. The password read from the WPHOST.DB file helps a GroupWise POA gain access to all the other message store databases in a post office. This adds a level of security to the GroupWise system. It prevents someone from creating their own GroupWise system and simply copying the message store databases into a different GroupWise post office.

What the WPHOST.DB File Provides to the POA

The POA reads its configuration information from the WPHOST.DB file. So when a POA is configured in ConsoleOne, those changes are replicated down to the WPHOST.DB file for the POA to read.

The POA discovers other information from the WPHOST.DB, including the following:

  • The administrator for the domain that owns this post office, which is important so that problems can be reported by the POA to the administrator.

  • The IP addresses and ports of the POAs that service the other post offices in the GroupWise system. This helps when a POA needs to hand a user off to another post office so that it can proxy into a user's email on a different post office.

  • The names of all mail recipients (users and resources), gateways, domains, and post offices. This way, if a user types an incorrect name, the POA can immediately tell the user of the error.

  • The TCP/IP port and address of the domain MTA that owns this post office.


Summary

The GroupWise directory is a fully replicated directory. All objects are broadcast to all other GroupWise domains. The GroupWise directory is separate from eDirectory, but is integrated with eDirectory to use the administration strengths of eDirectory. For example, without eDirectory rights to the primary domain, a secondary domain administrator can be excluded from being able to make system-wide changes in the GroupWise system. It's important to understand that all of this is platform independent and is similar on NetWare, Linux, and Windows.


Chapter 4. Understanding the GroupWise Information Store

The GroupWise information store consists of messages in post offices and documents in libraries. The GroupWise information store follows a distributed or partitioned model, in which different store files contain different portions of the entire store.

This chapter looks at these store files individually. It also details their relationships and considers the information store as a whole, spanning multiple post offices. The objective of this chapter is to help you understand GroupWise architecture well enough to troubleshoot your system effectively. The concepts discussed in this chapter will be applied in Part IV, "Practical Administration," and Part V, "Applied Architecture," and especially in Chapter 17, "Maintaining the GroupWise System."


The Post Office Directory Structure

The information store is entirely contained in the post office directory and its subdirectories. If you have more than one post office, your information store spans post offices, with each local store containing items particular to the users belonging to that post office. Figure 4.1 shows a post office directory.

Figure 4.1. The post office directory structure as viewed through Windows Explorer

There are four types of directories relevant to the discussion of the GroupWise information store:

  • Input and output queues

  • The OFUSER and OFMSG directories

  • The OFFILES directories

  • The GWDMS (GroupWise Document Management System) directory structure

These are discussed in the sections that follow.

How Input and Output Queues Are Used

There are three queue directory structures in a GroupWise post office: WPCSIN, WPCSOUT, and OFWORK. These queues store message files that are coming into the post office from another location, or that are outbound to another location.

The WPCSIN Directory

The WPCSIN directory, whether you see it at the post office level or under a domain directory, always does the same thing. It is the input queue for a GroupWise MTA (see Figure 4.2).

Figure 4.2. The WPCSIN directory under a GroupWise post office

The 07 directories under WPCSIN hold message transport files that need to be transferred to another location (domain, post office, or gateway). This means all the files here are outbound messages, from the perspective of the post office.

Note

The naming convention is a holdover from the old WordPerfect Office days. This directory name is really an abbreviation for WordPerfect Connection Server INput.

Tip

The queue directories were named from the perspective of the MTA. So no matter at which level you see the WPCSIN or WPCSOUT directories, think of their functions from the perspective of the MTA. Hence, the WPCSIN directory at the post office level is the MTA's input queue, and the WPCSOUT directory is the MTA's output directory.

Aside from the 07 queues, you will see a PROBLEM directory. This directory contains files that could not be processed for some reason, with the exception of files that could not be processed because a link was down. These files go into a holding queue elsewhere.

Following is an explanation of the subdirectories of WPCSIN. Each of these numbered directories serves a different purpose:

0: | Live, interactive request messages (busy searches, remote library queries, and agent restart)
1: | GroupWise remote mode (mailbox synchronization requests, shared folder and shared address book replication messages)
2: | Administration updates and high-priority mail messages
3: | Status messages from high-priority mail
4: | Normal-priority mail messages
5: | Status messages from normal-priority mail, low-priority administrative request
6: | Low-priority mail messages, low-priority administrative request
7: | Status messages from low-priority mail

You will find these directories in many places on the GroupWise system. Everywhere you find them, the queue assignments for each directory remain the same.

The WPCSOUT Directory

The meaning behind the name of the WPCSOUT directory is WordPerfect Connection Server OUTput. This directory, as shown in Figure 4.3, contains things that the MTA (long, long ago known as the connection server) has transmitted to the post office. This directory contains messages that are inbound for the post office.

Figure 4.3. The WPCSOUT directory under a GroupWise post office

There are four subdirectories in the WPCSOUT directory: ADS, CHK, OFS, and PROBLEM. The ADS and OFS directories contain the familiar 0-7 queues. The CHK directory is new with GroupWise version 6 and later. It has only directories 03 and the DEFER directory. Following is a short explanation of the messages that are queued to these directories:

  • ADS: Administration updates.

  • CHK: GWCHECK jobs sent to the POA (Post Office Agent).

  • OFS: Information store updates (user email, notes, tasks, and so on).

  • PROBLEM: Where problem messages go.

Remember, though, that these are queues. User email does not exist in the OFS/07 structure for very long. These files are dropped there by the MTA, or by the POA's MTP thread, and then the POA processes these items further.

The OFWORK Directory

The only directory in the OFWORK directory is the OFDIRECT subdirectory. The OFWORK\OFDIRECT directory is used by the GroupWise remote client. Queue directories are created for each remote user, and these directories serve as input and output queues for remote requests, which then move through the WPCSIN\1 or WPCSOUT\OFS\1 directories for processing.

Note

The GroupWise 6.5 and 7 versions use the OFWORK\OFDIRECT directory much less now when the GroupWise client is in remote mode. Updated remote technology (live remote) bypasses this directory most of the time, which facilitates much quicker access for remote users. The only time the OFWORK\OFDIRECT queues are used is when the GroupWise client is using an older batch remote mode to communicate with the post office.

The Function of the OFUSER and OFMSG Directories

The core of the GroupWise information store is found in the OFUSER and OFMSG directories. These directories contain the user and message databases in which all mail items are stored as database records. The section of this chapter titled "The Core of the Messaging System" covers the user and message databases.

The Purpose of the OFFILES Directories

In most GroupWise systems, the majority of the disk space (often up to 80%) that is used by the information store is actually used by attachment files and BLOB files (Binary Large OBjects) in the OFFILES directory structure. The OFFILES directory has up to 255 subdirectories, hexadecimally numbered. Figure 4.4 shows a portion of an OFFILES directory structure.

Figure 4.4. The OFFILES directory structure found under a GroupWise post office

[View full size image]

Storing Libraries in the GWDMS Directory Structure

The GWDMS directory and its subdirectories are the home for any GroupWise libraries that have been created under this post office. Figure 4.5 shows one library created under this post office's GWDMS directory.

Figure 4.5. The GWDMS directory structure found under a GroupWise post office

In Figure 4.7, shown later in this chapter, the GWDMS directory structure has been expanded to illustrate the deeper structure. More discussion about the GroupWise Document Management System is found in the section "The GroupWise Document Management System."

Figure 4.7. The library directory name is reflected in the name of each of the files contained therein

Previous Page
Next Page


The Core of the Messaging System

The exploration of the post office directory structure earlier in this chapter briefly discussed the relationships between the various files. This section covers these relationships in more detail.

The User Database

Every user in the GroupWise system is assigned to a unique user database per post office. These files are found in the OFUSER directory. They follow the naming convention USERxxx.DB, in which xxx is replaced with the three-character file ID for the user.

Note

Customers who have migrated from WordPerfect Office might on occasion have users with a two-character file ID.

This file ID, or FID, is alphanumeric, which means that you can have up to 46,656 uniquely named user databases on each GroupWise post office. The FID must be unique at the post office level, but no such restrictions exist system-wide. Users are also assigned a globally unique ID, or GUID, to ensure uniqueness system-wide, but this string is far too long to be conveniently used as part of a filename.

Contents of a User Database

The user database contains the following types of records:

  • Pointers

  • Personal items

  • Folders

  • Personal address books

  • Preferences

These five record types are explained in the sections that follow.

Pointers

When you open a user mailbox with a GroupWise client, you will see a list of folders, and in each folder you will see different items. These are simply database records. Each item record contains enough data to make the display meaningful, but the item itself usually exists in a different database. The item records found in the user database serve as pointers to the items in message databases. There are also special pointers, called document references, that point to records in GroupWise libraries.

Personal Items

Some items are completely contained in the user database, however. These posted or personal items do not have recipients or senders. Personal notes, tasks, and appointments, as well as posted items, fall into this category.

Folders

All the items in a user mailbox can be stored in several folders, and this folder structure is also stored in the user database. This means that whenever a user database needs to be re-created, all nonpersonal items can be restored again from the message database, but these items will be in the system Cabinet folder without the earlier folder structure.

Personal Address Books

Addresses that users enter and groups that users create exist in the personal address books. One such book is the frequent contacts list, which is populated automatically with the addresses of individuals with whom you exchange email.

Preferences

Many user settings and preferences are kept in the user database. These include rules, send options, categories, button bars, proxies, signature options, and the user password. Other settings, such as window positions, are kept in the Windows Registry.

Message Database Content

Prior to GroupWise 7, on every GroupWise post office, you would find up to 25 message databases. These files follow the naming convention MSGn.DB, in which n is a number from 0 to 24. Message databases contain group itemsitems that have been sent from one user to other users.

With GroupWise 7, architectural changes have been made so that the system can make more than just 25 message databases. In fact, with GroupWise 7 there is now a potential of 255 message databases.

When a message is delivered to a user, that user gets a pointer in his or her user database. The pointer points to the actual message item record in a message database. When a user reads a subject line from the Mailbox folder, the text comes from the item record in the user database. When that user double-clicks the message to open it, the pointer is followed, and the resulting window is populated from the appropriate item record in a message database.

The User Database/Message Database Relationship

When a GroupWise user sends a message, the complete item record is first written to the sender's message database (which is shared with other users). Next, a pointer is written to the sender's user database. This shows up as a sent item. If the message was sent to a user in the same post office as the sender, the recipient's user database gets a pointer to the same message, which exists in the message database. If the recipient exists in a post office different from the sender's, when the message arrives at the destination, it is written first to the same message database as the sender's. The destination user's user database then receives a pointer to the local message database.

Every message a user sends will be written to the same message database. Each user is assigned to a message database for sending based on the user FID.

Item records in message databases contain all data pertaining to that item, including status informationwhen it was delivered, opened, or deleted, or when any other action was performed against it. If items are attached to a message, they will also be included as part of that item record, unless the item is larger than 2KB. Attachments, message bodies, or any other item fields that exceed 2048 bytes in length are written as separate records called binary large objects (BLOBs).

Binary Large Objects (BLOB Files)

In the OFFILES directory, there are up to 255 subdirectories. Each of these can contain binary large object files. These BLOB files are standalone records. They are referenced as records by pointers in user and message databases, and they contain any field data for item record fields that exceed 2048 bytes in length. Following are just a few examples of how BLOB files are created:

  • With attachments: If you attach a 2MB file to a mail message, you end up creating a BLOB file in the OFFILES structure, as well as a message record in your assigned message database. If your attachment is less than 2KB, however (say, a 1000-byte autoexec.bat file), the attachment is encoded as a field in that message record, it exists entirely within your assigned message database, and no BLOB file is created.

  • With long messages: If you type a 10-page message and send it, your mail item exists as a record in the message database you are assigned to, but the text of that message is now in a BLOB file somewhere in the OFFILES structure. This is simply because the length of your message exceeds the 2KB limit stored in each record of the message database.

  • With multiple addressees: If you address a message to every user in your company, your TO: field will very likely exceed 2048 bytes in length. Thus, your message body record could exist in your assigned message database (if it's under 2KB), but the distribution list for that message will be in a BLOB file.

BLOB files are given hexadecimal names with alphanumeric extensions. They are encrypted using GroupWise's native 40-bit encryption, and they are compressed as well. BLOB files in the OFFILES structure cannot be read independently; they must be opened by following the appropriate item pointers via the GroupWise client.

The Purpose of the Deferred Message Database

In the OFMSG directory, there is a special-purpose database, used for delayed delivery messages and for special item lists used by the system when GroupWise mailboxes are moved between post offices. This file, named NGWDFR.DB, is called the deferred message database.

There are two operations a user can perform that will result in records being written to this database:

  • Sending a message with Delay Delivery checked

  • Sending a message with Expiration Date checked

You can check both of these options for individual items from the Send Options tab of a message you are composing. You can make these settings for all items by choosing Tools, Options, Send from the GroupWise client.

Delayed Delivery

When delayed messages are sent, GroupWise must write to four places:

  • Message database: The message database, assigned to this user for send operations, gets the item record.

  • User database (of the sender): The user database gets a pointer, as usual.

  • Deferred message BLOB: The message in its entirety is kept in a special BLOB file. These BLOB files are kept in the OFFILES\FD0FDF directories.

  • Deferred message database: NGWDFR.DB gets a pointer to that item record, along with a date indicating when the item should be delivered to its recipients.

The reason the message is placed in its entirety as a BLOB file is that the message should not show up in the recipient's mailbox until the delivery time. Entries in NGWDFR.DB tell the POA when to deliver a message, as well as which BLOB file corresponds to that message.

Messages with Expiration Dates

When a message is sent with an expiration date, it is sent normally. That is, records exist in the sender's user database, the recipient's user database, and the sender's assigned message database. An additional record is placed in NGWDFR.DB: a pointer to the message database record, along with the date on which that record should be deleted if it has not yet been opened by the recipient.

Tip

Although you can set expiration-date options globally, this is a very poor way to manage mailbox size. Expired items are deleted only if they are unread, and the NGWDFR.DB database file will grow to be quite large if it must keep track of every sent message.

How Prime User Databases Are Made

To explain the function of a prime user database, this section uses variables, like in high school algebra.

A prime variable is one that represents a new iteration of the original variable. A prime user database is a new iteration of the original user database, containing only a subset of the contents of that original database.

Now, if you are not mathematically inclined, that example might not work. Here's an approach to the prime user database in terms of functionality.

When a user shares a folder or an address book with a user on another post office, a prime user database will be created on that post office. This database will contain any shared folders or address books the user has shared with anyone on that post office.

The items that go into a shared folder are written either to the appropriate message database on the sharee's post office, or, in the case of personal and posted discussion items, directly to the prime user database.

Prime user databases cannot be named the same way user databases are. On large systems, the capability to create uniquely named databases would be compromised. Thus, they are named as PUnnnnnn.DB, in which nnnnnn is a six-digit number. This number is in two-byte hexadecimal pairs, beginning with 020101.

The first shared folder to arrive at a post office will arrive in PU020101.DB, regardless of which user shared the folder. The next user who shares a folder or an address book with that post office will end up creating PU020102.DB.

PU databases are created only for folders or address books that are shared across post offices. If they are shared with users on the same post office only, they will be accessed through the sharing user's USERxxx.DB file.

Using the Mailbox Index to Find Mailbox Items

Every item on the GroupWise system is full-text indexed. This allows the powerful Find feature of the GroupWise client to locate items in your mailbox, even if you have forgotten which folder you filed them in. This full-text index is created by the POA during the QuickFinder Indexing process.

There are actually two sets of indexes in a GroupWise post office. The mailbox index is found in OFUSER/INDEX. There is a library index as well, which is discussed later in this chapter.

In the OFUSER/INDEX directory, there are two types of files:

  • *.IDX: The permanent index files. They are updated and renamed at the end of each day. There is typically one of these for each user mailbox.

  • *.INC: The incremental index files. They are created during each QuickFinder Indexing run, and at the end of each day they are appended to the appropriate *.IDX files.

The names of these files are based on the time they were created or updated. The filenames are in hexadecimal format, so the file 000000F1.INC was created before the file 000000FF.INC.

Keeping Track of Databases with the Guardian Database

With all the various files floating around in a GroupWise post office directory, a central naming authority is required. The NGWGUARD.DB file, or the guardian database, is the central naming authority. This file contains a catalog of every database in the GroupWise information store on this post office. Any process that needs to work with a GroupWise database must first hook into the guardian database.

Because NGWGUARD.DB represents a potential single-point-of-failure, the GroupWise POA backs up this file each time it loads, as well as at midnight. Here's how the process works:

1. | The POA loads and checks the structure of NGWGUARD.DB. If it checks out okay, the process skips to step 5.
2. | The POA renames the bad NGWGUARD.DB to NGWGUARD.DBA.
3. | The POA copies the last backup, NGWGUARD.FBK, to NGWGUARD.DB.
4. | The POA writes all transactions from NGWGUARD.RFL (the guardian roll-forward log) to NGWGUARD.DB. The POA now has a clean NGWGUARD.DB, with all transactions made since the last backup rolled back into it.
5. | The POA copies NGWGUARD.DB to NGWGUARD.FBK and to OFMSG\GUARDBAK\NGWGUARD.FBK.
6. | Delete NGWGUARD.RFL and create a fresh, blank version of this file.
7. | When changes are made to NGWGUARD.DB, write these changes to NGWGUARD.RFL.

This is how the changes between guardian backups are stored for recovery.


The User and Message Database Relationship

It might be helpful at this point to illustrate the way the user and message databases work together. Figure 4.6 shows the relationship between user and message databases.

Figure 4.6. The connection between user and message databases

In the example shown in Figure 4.6, the user assigned to USER123.DB has sent a message to another user. USER123.DB is assigned to send through MSG17.DB, and has sent to USERABC.DB. The following numbered items correspond to the numbered arrows in Figure 4.6:

  1. In the USER123.DB file, there is a record for a sent item. This record has a pointer to the message item record in MSG17.DB.

  2. In MSG17.DB, there is an item record that was created by USER123. This item contains an attachment that is larger than 2048 bytes, so that attachment data is written to a BLOB file. The item record contains a pointer to this BLOB file in the OFFILES directory structure.

  3. In USERABC.DB, there is a record for the item received from USER123. This record contains a pointer to the message item record in MSG17.

From this simplified illustration, you can see that even if a dozen users on a post office have a copy of a message in their inbox, that message record exists only once in the appropriate message database. An attachment sent to several people is written to only one BLOB file.


The GroupWise Document Management System

If a GroupWise post office has no libraries, the GWDMS directory will not contain any data. After libraries have been created, though, the structure beneath GWDMS becomes fairly complex.

Shared Document Management Services Database (DMSH)

This file, DMSH.DB, exists at the root of the GWDMS directory structure. It contains lookup tables for document type and other administrator-defined document property fields, as well as a list of the libraries defined under this post office. It does not contain any document data, but it is critical to the functionality of the Document Management System on this post office.

Library Directories and Naming Conventions

Regardless of what you name your library, the library directories created under the GWDMS directory follow a numeric naming convention, beginning with LIB0001 and hexadecimally numbered through LIB00FF.

The last two characters of the directory name become the library number. As you can see in Figure 4.7, this number is used throughout the library directory structure for the naming of files found in library directories.

In Figure 4.7, the last two characters of every file in the LIB0001 directory are 01 (excluding the .DB extensions, of course). Following is a look at each of these databases in turn.

Library Database

DMSD00xx.DB is the library database, in which xx is replaced with the two-digit hexadecimal library number. This database contains the table of document numbers, as well as property-sheet field layout information for this library. It contains no document data but is critical to the function of the library.

Document Properties Database (DMDD)

There are 10 document properties database files; they should be treated as a single database that has been partitioned into 10 files. The naming convention is DMDDppxx.DB, in which pp is replaced by a partition number 00 tHRough 09, and xx is replaced by the library number.

The document properties database contains all information entered into document property sheets. This includes document subject, author, type, associated application, and much more. The property sheet is one of the key benefits to the GroupWise Document Management System, because it allows information about the document to be stored and searched for independently of the document itself, while maintaining a relationship to the document.

Each document record contains three kinds of pointers. The first pointer is to the document BLOB file (discussed later in the section "Document BLOB Files"). The second is to the document's activity log (discussed in the next section). The third pointer points to any user database that contains a document reference to this document. This pointer is used to provide the mailbox indexing process with a word-list file for this document. In this way, a search for full-text of the document returns the document reference, even if the user did not specify a search of GroupWise libraries.

The last digit of the document number indicates in which DMDD partition the document's property sheet record resides. For example, document 1762 in this library is referenced in DMDD0201.DB, and document 21265's properties are in DMDD0501.DB.

Document Logging Database (DMDL)

There are also 10 document logging database files. Again, they should be treated as a single database spread across 10 partitions. The naming convention is DMDLppxx.DB, in which pp is the partition number 00 through 09, and xx is the library number.

The document-logging database contains all activity logs for documents in the GroupWise libraries. Any action that affects a document is logged in this database, including opening, closing, viewing, downloading, uploading, and deleting. Also recorded in the DMDL files is the filename for the document BLOB on which the logged action was performed. When a document is viewed, the BLOB filename does not change, but any action that changes document content (closing it and, hence, checking it back in with possible changes) results in a new BLOB file being created. After the successful creation of such a new BLOB file, the old BLOB file will be automatically deleted, as it is not necessary anymore.

Document BLOB Files

Although the DOCS directory structure is very similar to that of OFFILES, the contents of the 255 DOCS subdirectories are very different from those of the OFFILES BLOBs.

Document BLOB files are created for every document, regardless of document size. Whereas OFFILES BLOBs are created only when field data exceeds 2048 bytes in length, document BLOBs are created even for a 0-byte document.

Word-List Files

There is another kind of BLOB in the DOCS subdirectories. Word-list files are created for each document when that document is indexed. These files contain, as their name suggests, a list of every word in that document. These files are used to build the .INC files (incremental index files), and are also used to provide mailbox indexes with the full-text information for any document references they might contain.

Document Compression

Document BLOB files are encrypted and compressed, just like OFFILES BLOBs, but they contain information that allows them to be manually opened by certain GroupWise users. The GroupWise client can read a BLOB file directly and determine whether the GroupWise user is supposed to have access to this BLOB (a user with the manage right for this library, or a user who has edited the document in the past). If the user is cleared for the document, it will be reimported, and a new BLOB and property sheet created. This might be useful for restoring documents that have been deleted but whose BLOB files exist on backup media.

Document BLOB files are typically around 50% smaller than the documents in their native formats. Pure text documents can be reduced to 10% of their original size, whereas compressed graphic formats (such as GIF or JPEG documents) cannot bereduced.

Document Index

All documents are full-text indexed. This is another selling point of GroupWise document management as a solution for document storage. Documents can be found using the GroupWise client to search for words they contain, or for field data recorded in their property sheets.

Inside the INDEX subdirectory, there are 10 active and permanent index files. These files have an .IDX extension. There are also many .INC files containing the incremental indexes. Just like the mailbox index, the POA QuickFinder Indexing process creates the document index. The .INC files are created from the word-list BLOB files discussed earlier. At the end of the day, all .INC file content is written into the .IDX files, and the .IDX filenames are updated.


Document Reference Relationships

Figure 4.8 explores the relationships between the various GroupWise information store databases when document references are being employed.

Figure 4.8. The complex system of pointers created when document references are employed

The following is a discussion of the items that appear in Figure 4.8:

  • The user assigned to USER123.DB creates a document in a GroupWise library. It is the ninth document created in this library, and it has been assigned document number 9.

  • This library is the first one created on this post office, and it is in the LIB0001 directory.

  • USER123 has also created a document reference, a pointer in his Documents folder enabling him to quickly find document number 9.

  • USER123 attaches this document reference to a mail message and sends it to another user.

The following numbered items correspond to the numbered arrows in Figure 4.8:

  1. The document reference is a pointer to the document property record. The document property record has a back link to this document reference (the arrow points both ways). Because this is document number 9, library 1, its property sheet is in DMDD0901.DB.

  2. The document property record has a pointer to the actual document BLOB file in the DOCS directory structure.

  3. The document property record has a pointer to the activity log record for this document. The activity log has a back link to the property record (again, the arrow points both ways).

  4. The activity log record for this document is in DMDL0901.DB, because this is document number 9 in library 1. This record has a pointer to the BLOB file for this document.

  5. When the user sends the document reference, a message item record is created in MSG17.DB. USER123.DB has a pointer to this item record.

  6. The item record in MSG17.DB contains a document reference, which means it has a pointer to the document property record in DMDD0901.DB. That document property record has a back link to MSG17.DB.

Note

For simplicity's sake, the recipient's mailbox is not shown in Figure 4.8. That mailbox would have only a pointer to MSG17.DB for the received item.

The document property record "knows" more about this document than any other database or record shown. When the POA needs to index this document, it reads this property record to find all document references and makes sure that the word list generated for this document is accessible when the mailboxes containing those references are indexed.

Note

As of the initial writing of this book, all the features of GroupWise Document Management are not configurable if a GroupWise post office is deployed on a Linux server. Specifically, the use of customized document fields is not supported. Remote document storage locations also are not supported.


For More Information

The GroupWise Document Management System is very complexso complex that document management really warrants its own book on the subject. If you are considering implementing GroupWise Document Management, you should consider obtaining the book Success with GroupWise Document Management, available at www.caledonia.net.


Summary

The GroupWise information store employs a mixture of strategies. Partitioning is used on user mailboxes so that message items are not unnecessarily replicated. A different sort of partitioning is used on document property and activity databases, to keep these files at manageable sizes even on large libraries. A third type of partitioning is used for document files and for long strings of field data; the binary large object files can be considered partitions of the message databases or the document databases, depending on their content.

Replication is used across post offices. Shared folders and address books are replicated to prevent unnecessary network utilization when users access these items. Messages sent between post offices are replicated once per post office, again, so users reading these messages do not need to open client/server connections to the sender's post office.

This replication across post offices is managed through database record numbers (DRNs) and GUIDs. Items replicated to other post offices are linked back to the original item record. When users are moved, or folders are shared, and another copy of an item ends up on a post office, the duplicate DRN or GUID tells the delivery process to create a pointer to the existing item, instead of writing the item again.


Part II: Administration Interface

5 Working with GroupWise Objects

6 Using GroupWise System Operations

7 GroupWise Utilities and Diagnostics


Chapter 5. Working with GroupWise Objects

This chapter looks at how some of the GroupWise entitiesdomains, post offices, and so onare represented as objects in ConsoleOne. ConsoleOne is the tool you use for most of your GroupWise administration.


The GroupWise View

From ConsoleOne, you access the GroupWise view by doing the following:

1.
Choose Edit, Preferences.

2.
Check the Show View Title option. This way, it is easy to distinguish when you are in GroupWise view.

3.
Select the GroupWise System icon, which displays the window shown in Figure 5.1.

Figure 5.1. The GroupWise view

[View full size image]

This window displays your GroupWise system and does so in a way that clearly illustrates the relationships between domains, gateways, post offices, and other objects. The window is divided into two side-by-side panes.

The System pane, on the left in Figure 5.1, displays the GroupWise system and the domains and post offices. The display follows the GroupWise domain and post office hierarchy: Domain icons are at the first level, and post offices are at the second level.

The Object pane, on the right in Figure 5.1, displays all possible GroupWise objects, including domains and post offices. Because either a domain or a post office must own all GroupWise objects in the GroupWise view, these objects are viewable only on the Object pane on the right.

Filtering the GroupWise View

The Object pane cannot display all types of GroupWise objects at once. An object filter drop-down menu determines the types of objects that are viewable.

The drop-down filter shown in Figure 5.2 provides up to 10 types of filters for easily maneuvering among GroupWise objects.

Figure 5.2. The GroupWise view drop-down filter

[View full size image]

Creating GroupWise Objects

You can create GroupWise objects, especially user objects, from either the GroupWise view or the eDirectory view in ConsoleOne.

To create a GroupWise object from the GroupWise view, do the following:

1. | Highlight the GroupWise System or a domain or post office. Right-click and select New. For example, you might want to create a new user and immediately associate that user with the CORPPO post office.
2. | Select the CORPPO post office, and right-click.
3. | From the New menu item, select User.
4. | Proceed through the object-specific dialog boxes.

This method enables you to create an eDirectory user and assign the user to a post office with a mailbox in essentially one step.


Viewing the Domain Object

Generally, you do not administrate the domain object much after you have initially configured it. However, you will often find that when you are troubleshooting, you will go back to the domain object to confirm how it is configured.

Note

One of the reasons to administer the domain object right after creating your new system or new domain is to add an "administrator" account to the domain object. Failure to do so will mean that you will not receive all sorts of useful administrative messages. You'll find more details about this admin account in the next section.

If you highlight a domain, right-click, and select Properties, you'll get a window like the one shown in Figure 5.3.

Figure 5.3. The domain object properties window

[View full size image]

The domain object properties window has six property pages, selectable by clicking the word on the GroupWise tab:

  • Identification

  • Post Offices

  • Address Book

  • Addressing Rules

  • Internet Addressing

  • Default WebAccess

The following sections offer a discussion of each of these pages in turn.

The Domain Identification Property Page

The Identification page displays all the general information about this domain. There are nine fields, as shown in Figure 5.3, but only six of them can be edited:

  • Domain: The domain name cannot be changed after the domain has been created. If naming conventions at your organization require you to change a domain name, you must create a new domain by that name and move users to it. Refer to Chapter 13, "Moving Users," for more information.

  • Description: The optional text you place in this field can be used to help other administrators contact you. This text is never visible to users, or from the server console.

  • UNC Path: This field should be populated with the Universal Naming Convention (UNC) path to the domain database for this domain. The syntax for a UNC path is \\server name\volume\path to domain database. When you use the System Connection tool to switch domains (covered more fully in Chapter 6, "Using GroupWise System Operations"), ConsoleOne requires the UNC path value. If a domain is located on a Linux server, the path indicated here would not look like a UNC path. It might look something like this: /data/corp.

  • Language: This drop-down menu is populated with the available languages. Be sure to select your local language so that your users will get the system messages, if any, in their own preferred local language instead of in English.

  • Domain Type: A domain that is part of your GroupWise system will show as either Primary or Secondary (and only one domain will be the primary). Domains belonging to other systems that your system sends messages to will show as External. Another type of domain that is created for special routing purposes is called a Non-GroupWise domain.

  • Time Zone: This field is populated from a drop-down menu containing all the widely recognized time zones worldwide. This field is critical if your organization spans multiple time zones, or if you share email with organizations in other time zones.

  • Database Version: In this field, you will see 4.1, 5.0, 5.5, 6, 6.5, or 7. A 4.1 identifies a GroupWise 4.1 domain, whereas a value of 5.0 applies to any version of GroupWise 5.0, 5.1, or 5.2. If a domain is running GroupWise 5.5 or GroupWise 5.5 Enhancement Pack, this field reads 5.5. A GroupWise 6 domain reads 6. For a GroupWise 6.5 domain, this field reads 6.5. A GroupWise 7 domain reads 7. This field is important to keep an eye on if you are upgrading from an earlier version of GroupWise.

  • Network Type: This field is a holdover from WordPerfect Office 4.0 days and can be ignored.

  • Administrator: The Browse button for this field enables you to choose an eDirectory user object to serve as the GroupWise administrator. The object you select must have a valid GroupWise mailbox associated with it. Any error messages generated by GroupWise agents are emailed to this user.

The Domain Post Offices Property Page

Simply put, this tab lists the post offices that belong to this domain. Because post offices cannot be moved or renamed, the information in this tab is not editable. Post offices can be deleted from this page, however. Post offices can be deleted only if they do not own any objects (such as users, resources, distribution lists, libraries, and POAs).

If you want to know what post offices a particular domain owns, it is often easier just to expand the hierarchy under this domain in the System pane of the GroupWise view. All the post offices will appear there.

The Domain Address Book Property Page

This is the interface for administering the way the system address book appears to your users. In the Windows client, this address book appears under the Novell GroupWise Address Book tab, as shown in Figure 5.4.

Figure 5.4. The domain object address book property page

[View full size image]

Using this tab, you can change the sort order, the field order, and the field labels in the address book for this domain. You can also add fields to the GroupWise address book.

Warning

This feature set is somewhat limited, though. For example, if you change the sort order from a system level, users can change the sort order to whatever they like, and you can't dictate what they choose.

These are the default fields:

  • Sort Address Book By: This tool has only two available values: Last Name, First Name and First Name, Last Name. As expected, the first option would put "Zachary Abrams" above "Allan Zane"(sorting alphabetically by last name). The second option would put "Allan Zane" above "Zachary Abrams."

  • Address Book Fields and Available Fields: The interface here is a little tricky:

    • The left- and right-pointing arrows move fields into and out of the address book, respectively.

    • The up and down arrows change the order of the fields by moving the selected field up or down.

    • The Edit Label button enables you to change the field label of the selected field. Note: The only fields you can edit are Administrator-defined fields.

    • The Map Additional Fields button opens a new window. This feature enables you to define additional fields for user objects, which are then available in the GroupWise address book. Chapter 6 talks in detail about how you might use this powerful feature to extend the capabilities of the GroupWise address book.

The Domain Addressing Rules and Internet Addressing Property Pages

The Addressing Rules property page enables you to set and test existing addressing rules. It does not allow for the creation of addressing rules, however. You create addressing rules from the System Operations window. Chapter 6 goes into more detail on creating addressing rules.

The Internet Addressing property page enables you to override system-wide Internet addressing settings at the domain level. It also lets a GroupWise system use native Internet-style addresses for GroupWise users and resources. This page allows for wide ranges of flexibility in regard to how users' Internet-style addresses are maintained and used. At this point, it is important to know that Internet addressing is a very powerful tool, and like any good power tool, it can take your fingers off. Chapter 16, "Internet Addressing," discusses Internet addressing. For now, leave it unplugged and put it back down between your table saw and your workbench.

The Domain Default WebAccess Property Page

Use the Default WebAccess property page to select the default WebAccess agent (gateway) that processes requests for users located in this domain. This page applies only if you have multiple WebAccess agents installed in your GroupWise system. If you have only one WebAccess agent, that WebAccess agent services users in all domains. Chapter 11, "Installing and Configuring GroupWise WebAccess," discusses how to use this feature for practical purposes.

The following bulleted items explain the purpose of the different selections on this property page:

  • Default WebAccess: When you have multiple WebAccess agents and a user logs in to GroupWise WebAccess, the GroupWise WebAccess Application (running on the Web server) determines whether a default WebAccess agent has been assigned to the user's post office (Post Office object, GroupWise tab, Default WebAccess page). If so, the WebAccess Application connects to the assigned WebAccess agent. If not, it connects to the default WebAccess agent assigned to the post office's domain that you define from this page.

    If possible, you should select a WebAccess agent that has the best network-level access to the domain's post offices to ensure the best performance. Each post office will use the domain's default WebAccess agent unless you override the default at the post office level (Post Office object, GroupWise tab, Default WebAccess page).

  • Override: Check this box to indicate that you want to assign a default WebAccess agent to the domain.

  • Default WebAccess Gateway: Browse for and select the WebAccess agent you want to use as the default.

This section has explained how settings can be made at the domain level. Some of these settings can also be made at the post office level. The value of making a setting change at the domain level is that several post offices can be changed at the same time. The notion of a domain administration model helps GroupWise to be administered at a higher level. When GroupWise is administered at a higher level, post office administration can be less taxing.

There are many more property pages to administer under a GroupWise post office versus a domain. However, the purpose for this is flexibility. For example, if you want a post office to be configured differently from other post offices in a domain, some of the defaults that are specified at the domain level can be customized to the requirements of a particular post office.


Viewing the Post Office Object

Figure 5.5 gives a detailed look at the post office details window.

Figure 5.5. The post office object properties page

[View full size image]

As with the domain properties window, the post office properties window has several property pages:

  • Identification

  • Post Office Settings

  • Client Access Settings

  • Membership

  • Resources

  • Distribution Lists

  • Libraries

  • Gateway Aliases

  • Internet Addressing

  • Security

  • Default WebAccess

The Identification Property Page

The fields on the Identification property page are shown in Figure 5.5. Only two fields are non-editable. The remaining four fields on this property page will generally stay the same.

These are the options you'll find here:

  • Post Office: This field displays the post office's GroupWise object ID (or "name" to you and me). Post offices cannot be renamed after they have been created. As with domains, if you need to rename one for some reason, you will have to create a new post office and move your users between the two. Moving users is covered in Chapter 13.

  • Description: This optional field might be a good place to enter your pager number, or perhaps special instructions for system operators. The text here is visible through this window only.

  • UNC Path: This field shows the path to the post office database, WPHOST.DB. Incorrect information here can foul network links and can prevent you from successfully running system maintenance on the post office database. If a post office is located on a Linux server, the path indicated here would not look like a UNC path. It might look something like this: /data/corppo.

  • Language: This field shows the language for this post office. Be sure to select your local language so that your users will get the system messages, if any, in their own preferred local language instead of in English.

  • Time Zone: This is the time zone for this post office. Changing this setting will result in chaos among the users on this post office, because all the appointments on their calendars at the time of the change will move. Time zones should be carefully selected when you create the post office, and then you should leave them alone.

  • Database Version: As explained in the section "The Domain Identification Property Page," this will be 4.1, 5.0, 5.5, 6, 6.5, or 7.

  • Configure Non-DOS Name Space Access: If you are running in direct access mode, and you have GroupWise clients running on platforms that do not recognize UNC paths, and you want those clients to obtain the post office path from eDirectory, you'll need to use this button. Enter the path style that your clients prefer into the appropriate field in the resulting dialog box. This setting really is here to be backward compatible to GroupWise 5.xlevel post offices and is rarely used anymore.

The Post Office Settings Property Page

The Post Office Settings property page is packed with features specific to a post office. Here's an explanation of each of the options on this page:

  • Network Type: This field is obsolete and can be ignored.

  • Software Distribution Directory: This pull-down menu is populated with the names of each of the Software Distribution Directories (SDD) you have created in this system. Assigning an SDD to a post office provides the GroupWise client with a UNC path for client updates. Chapter 12, "Administering the GroupWise Client," discusses software distribution directories in more detail.

  • Access Mode: There are three options here:

    • Client/Server Only: The client "talks" via IP (Internet Protocol) to the POA. The POA handles all message store transactions. Users do not need any file-system rights to the message store to run in client/server mode. (This is the preferable mode for running the GroupWise client.)

    • Client/Server and Direct: The client attempts a client/server connection, and if that fails, it attempts to connect in direct access mode. This mode is not a hybrid. Clients always connect in only one manner. All this mode offers is the flexibility to support a mix of machines with and without IP addresses.

    • Direct Only: The client performs all mailbox transactions directly on the message store. It does not talk to the POA at all but will access the message store directly. This is not a recommended mode to run your GroupWise clients in.

    • Delivery Mode: This setting applies only if users are allowed to use the direct connection. For users with direct-access connections, the setting applies as described here:

    • Use App Thresholds: The client writes to the sending user's USER and MSG databases, and, if the threshold is not exceeded, also writes to each recipient's USER database.

    • Client Delivers Locally: The client writes to the sender's USER and MSG databases, as well as to the USER database for every recipient on the local post office.

Warning

Novell recommends that clients connect to the post office only in client/server mode. Direct mode, regardless of the delivery mode selected, poses a security and a stability risk to the message store. In direct mode, users must have file-system rights to the message store, and store files are subject to corruption if a workstation crashes.

  • Disable Live Mode: Select Disable Live Move to turn off the improved move-user capabilities available in GroupWise 6.5 and GroupWise 7.

    A live move uses a TCP/IP connection to move a user from one post office to another. In general, it is significantly faster and more reliable than earlier move-user capabilities in GroupWise 5.x. However, it does require that both post offices are running GroupWise 6.x or 7.x POAs, and that TCP/IP is functioning efficiently between the two post offices. Moving users and live-mode user moves are both discussed in Chapter 13.

  • Exempt This Post Office from the Trusted Application Routing Requirement: This feature is made available for third-party integration with the GroupWise POA and MTA. It's an obscure feature that you should check only if you are instructed to do so when installing software that integrates with the GroupWise POA. An example is a server-based virus scanning utility that integrates with GroupWise.

  • Remote File Server Settings: Use the remote file server settings to provide the POA a login ID to use when connecting to another file server. This is used to access a remote machine where a GroupWise library, a document storage area, or restored post office databases are located. The POA might also connect to a GroupWise Software Distribution Directory on another server using this same login information. The Remote File Server Settings are not needed unless the POA will need to connect to a remote file server for any of the aforementioned purposes.

  • Remote User Name: Specify the network USERID for the POA(s) of this post office to use when accessing a remote file server. For example, GWMAIL.EMAIL.ACME identifies the eDirectory USERID that the POA will use to authenticate to the remote server.

  • Remote Password: Specify the password associated with the login ID provided in the Remote User Name.

Note

The remote user name and password must have the necessary rights to access the remote file server and perform whatever action the POA has been instructed to perform.

The GroupWise Post Office Settings page is not a page where you will be making frequent changes. Most of your post offices will be configured in the same manner under the post office settings page.

The Post Office Client Access Settings Page

The Client Access Settings property page allows you to lock out older clients, or users that might be trying to get into another user's account without authorization. Settings that can be configured here include the following:

  • Minimum Client Release Version (x.x.x): This is a great way of keeping users with an older GroupWise windows client out of your post office. However, if users are denied the ability to connect to your post office because their GroupWise client is too old, they are not prompted to upgrade their client in any manner. To determine the Client Release Version of a GroupWise client, select Help, About GroupWise within the GroupWise Windows client. Look at the program release; it will read 7.0, or something similar.

  • Minimum Client Release Date: This feature is very similar to the Minimum Client Release Version. A GroupWise client has both a release version and a release date. This is a great way of keeping users with an older GroupWise windows client out of your post office. However, if users are denied the ability to connect to your post office because their GroupWise client is too old, they are not prompted to upgrade their client in any manner. To determine the Client Release Date of a GroupWise client, select Help, About GroupWise within the GroupWise Windows client. Look at the program release; it will read something similar to 9/4/2005.

  • Disable Logins: If this is checked, users cannot log in to their GroupWise mailboxes on this post office. This option does not kick users out, however, if they are already logged in.

Note

If you need to kick users out in order to perform server or system maintenance, it helps if you are in client/server only mode. In this mode, you can simply unload the POA from the server console to kick everyone offanother reason to choose client/server only mode over the alternatives.

  • Enable Intruder Detection: Select Enable Intruder Detection to configure the POA for the post office to detect system break-in attempts in the form of repeated unsuccessful logins. For example, this could occur when someone repeatedly tries to log in but is using the incorrect password.

Tip

This feature is highly recommend when using WebAccess. Otherwise, intruders might try to get access to the mailbox by the method of password guessingtrying to access an account by using an automated procedure with an endless list of possible usernames and passwords.

  • Incorrect Logins Allowed: Specify how many unsuccessful login attempts trigger a lockout. The default is 5. Valid values range from 3 to 10.

  • Incorrect Login Reset Time: Specify how long unsuccessful login attempts are counted. The default is 30 minutes. Valid values range from 15 to 60 minutes.

  • Lockout Reset Time: Specify how long the user login is disabled. The default is 30 minutes. Valid values range from 15 to 60 minutes.

If a user account is locked out because it tripped the Intruder Detection code, you can go to the user's account and uncheck the Disable Logins check box on the GroupWise Account property page.

The Post Office Membership Property Page

The Membership property page provides a list of those users assigned to this post office. This tab comes equipped with tools to add existing eDirectory users to this post office, delete users from the post office, and move users between post offices.

The Post Office Resources, Distribution Lists, and Libraries Property Pages

These property pages provide lists of the various non-user objects associated with this post office. None of these objects can be created from the post office details window, so there are no Add buttons.

The Post Office Gateway Aliases Property Page

Post office aliases provide one way for a post office to be given a different Internet address than the rest of your organization. The Post Office Alias is generally useful only when you have defined an external post office. External post offices are explained in more detail in Chapter 19, "Building Your GroupWise System Correctly."

The Post Office Internet Addressing Property Page

Just as on the domain details screen, the Internet Addressing tab exists to enable you to make exceptions to the system Internet addressing configuration. Chapter 16 covers Internet addressing in detail.

The Post Office Security Property Page

There are two possible security values for a post office:

  • Low: Users' network logins are not checked to determine whether they correspond to the mailbox they are using. In this mode, mailboxes should be password protected. If they are not, any user can log in as any other user by placing the /@u-userID switch on the GroupWise command line.

  • High: Users' eDirectory passwords are checked before they can access their GroupWise mailbox. There are two methods GroupWise can use to get the eDirectory password: eDirectory authentication and LDAP authentication. Here's a discussion of both of these options:

    • With eDirectory authentication enabled, if a user has a Novell client that is authenticated to an eDirectory tree, the GroupWise 32-bit client queries the Novell client using a network API call. If a user is logged in as one person, but trying to open GroupWise as someone else, that user will be prompted for the mailbox password, which is not contained in eDirectory and requires that the mailbox truly have a GroupWise password.

    • WithLDAP authentication enabled, if users do not have the Novell client on their computers, or a user is using GroupWise WebAccess through a Web browser, they can still use an eDirectory password. The POA queries eDirectory via LDAP on behalf of the user. A prerequisite to this functionality is that your implementation of eDirectory be version 8.5 or better, with LDAP services enabled. Setting up LDAP authentication for the POA is explained in detail in Chapter 26, "Configuring GroupWise Authentication via LDAP."

The Post Office Default WebAccess Property Page

Use the Default WebAccess property page to select the WebAccess agent (or gateway) that will process requests from this post office's users. This page applies only if you have multiple WebAccess agents installed in your GroupWise system. If you have only one WebAccess agent, that WebAccess agent services users in all domains. Chapter 11 goes into more detail about how to use this feature for practical purposes.

The following are the choices you can make on the Default WebAccess page:

  • Default WebAccess: When you have multiple WebAccess agents and a user logs in to GroupWise WebAccess, the GroupWise WebAccess Application (running on the Web server) checks to see whether a default WebAccess agent has been assigned to the user's post office (Post Office object, GroupWise tab, Default WebAccess page). If so, the WebAccess application connects to the assigned WebAccess agent. If not, it connects to the default WebAccess agent assigned to the post office's domain.

    If possible, you should select a WebAccess agent that has the best network-level access to this post office to ensure the best performance. Each post office will use the domain's default WebAccess agent unless you override the default at the post office level.

  • Override: Check this box to indicate that you want to assign a default WebAccess agent to the post office.

  • Default WebAccess Gateway: Browse for and select the WebAccess agent you want to use as the default.


Configuring Library Objects

If you want to use document management, you will be creating library objects. To find any libraries that are already created, highlight the GroupWise System object in ConsoleOne, and then in the GroupWise view change the drop-down filter to Libraries. When you highlight a GroupWise library and view its properties, you will see a screen similar to that shown in Figure 5.6.

Figure 5.6. The Library Identification property page

[View full size image]

The Library Identification Property Page

This section includes a discussion of the fields that appear in the Library Identification property page, as shown in Figure 5.6:

  • Post Office: This field is the GroupWise domain and post office to which this library belongs. Libraries cannot be moved from one domain and post office to another, but with mass-change operations, the documents in one library can be moved to another.

  • Description: This is an optional field. The text here is not visible to users and is useful as a way to describe the library object to other system administrators.

  • Start Version Number: Document version numbers can begin at either 0 or 1. If you enter 0, the first version of each document will be 000. If you enter 1, the first version number will be 001. Most people count in ordinal terms, so it might be better to enter 1 here.

  • Maximum Archive Size in Bytes: This is the number of bytes per library archive directory. The value you enter should be compatible with your backup medium. For example, you could make it 90% of the tape backup's capacity to allow for the tape's file storage data. Then you can back up one archive directory per tape.

  • Display Name: Like domains and post offices, GroupWise libraries cannot be renamed. Fortunately, the display name for a library can be changed. This is visible to users when they select a library to save documents in.

  • Distinguished Name: This is the name and context of the GroupWise library object in eDirectory.

All of what you see on this property page will make more sense when you read Chapter 14.

The Library Storage Areas Property Page

As described in Chapter 4, "Understanding the GroupWise Information Store," GroupWise libraries are made up of document property databases (and other databases), and the documents themselves are stored as compressed, encrypted files called BLOB (binary large object) files. By default, all the databases and BLOBs are kept in subdirectories of the post office directory.

The Storage Areas property page enables you to choose other locations, whether they are on different volumes or even different servers, for the BLOB files. The document databases will always remain under the GWDMS (GroupWise Document Management System) structure, however.

By default, the box labeled Store Documents at Post Office is checked. You must uncheck it to add a storage area for documents. You cannot add document storage areas while this box is checked. Be sure to read Chapter 14 before deciding how you will store your documents.


Administering User Objects

Administering GroupWise user objects is the most common task you will be doing with GroupWise administration in ConsoleOne. This section fully explains all the attributes that can be administered on a GroupWise object.

The User GroupWise Account Property Page

If you have worked at all with Novell Directory Services and ConsoleOne, you are probably quite familiar with the user object details window. With GroupWise 7 installed in your tree, the user object has some new property pages available to it. The one you'll likely use the most is the GroupWise Account property page. Figure 5.7 shows this page.

Figure 5.7. The user object's GroupWise Account page

[View full size image]

Note

There is a special kind of user object that you may or may not see in your GroupWise system. It's what's called a "GroupWise External Entity." A GroupWise External Entity is a full GroupWise user, with an eDirectory object, but the eDirectory object is not a typical "red shirt" type user object. External Entity users have a green shirt. These users cannot authenticate to eDirectory, but they have an eDirectory object so that administrative rights can be assigned to the object

This tab offers three major administrative tools:

  • Changing GroupWise information for this user

  • Changing this user's GroupWise password

  • Deleting the user's GroupWise account

The following offers a discussion of each of the fields:

  • Post Office: This is the name of this user's post office, with the name of the domain tacked on before the post office name with a period delimiting the domain and post office names.

  • Mailbox ID: This is the user's GroupWise user ID for accessing the user's mailbox.

  • Visibility: This field defines which users elsewhere in the GroupWise system can find this user in the GroupWise address book. Following are the options for this pull-down menu:

    • System: Anyone on this GroupWise system can see this user in the address book.

    • Domain: This user can be seen only by users in the same domain.

    • Post Office: This user can be seen only by users in the same post office.

    • None: This user does not appear in the GroupWise address book.

      Just because a user cannot be seen in the address book does not mean that the user cannot be sent to. If you know the domain, post office, and user ID, you can enter those items in the TO field (for example, corp.corppo.tkratzer), and the email will reach the user.

      Similarly, if GroupWise Internet addressing is enabled, you can reach this user by entering the user's user ID and IDOMAIN (that is, tkratzer@wwwidgets.com) in the TO field.

  • External Sync Override: If you have connected your GroupWise system to another organization's GroupWise system, and are using external system synchronization, you might want to make some users invisible outside of your GroupWise system. This field enables you to override the setting in the Visibility field for this user.

  • Account ID: This field is used for GroupWise gateways that offer accounting features so that users can be charged for, say, sending faxes or transmitting data across an expensive line.

  • File ID: This is the three-character string that uniquely identifies this user's USER database in this post office directory. In the example in Figure 5.7, the File ID is 5nw, which means that the mailbox for user TKRATZER is in USER5NW.DB.

  • Expiration Date: If you have temporary or contract employees, you can choose to set an expiration date for them. After the date has passed, the user cannot log in to his or her GroupWise mailbox. Other users can still send mail to an expired user, however. Clearing the date out of this field after that date has passed will, in effect, un-expire the user, allowing that user to log in again.

  • Gateway Access: This is an obscure feature that was used in older GroupWise gateways. Use this field if instructed to do so when configuring a specific GroupWise gateway.

  • Disable Logins: If you need to prevent a user from logging in, you can check this box. Note that this change, as with any changes made in ConsoleOne, takes time to propagate down to the post office. Try to plan a few minutes ahead in order to ensure that the user doesn't successfully log in before the update takes place. If the post office that this user is a member of has Enable Intruder Detection enabled, when a user is locked out of his or her account, you should see a check mark in this box. If you uncheck the box, the user's mailbox will no longer be locked out.

  • LDAP Authentication: This option applies only if you are using LDAP to authenticate users (see "The Security Property Page" section earlier in this chapter) and the LDAP server is not the Novell LDAP server, or if the eDirectory tree you are using for LDAP authentication is a different tree than the one the users are in. Chapter 26 talks more about how you might use this field.

  • Restore Area: This option displays the restore area, if any, that the user can access to restore deleted items from backup.

    To set up a restore area, choose Tools, GroupWise System Operations, Restore Area Management. Restore area management is covered more in Chapter 28, "Restoring Deleted Users."

  • Change GroupWise Password: Clicking this option displays the Security Options window shown in Figure 5.8. The GroupWise password (managed with this Security Options window) is independent of the user's eDirectory password. So changing this password will not change the user's eDirectory password.

    Figure 5.8. The Security Options window

    This window offers the following options:

    • Enter New Password: If a user forgets a GroupWise password, you can provide the user with a new password to access GroupWise. You should advise the user to change the new password to a personal one.

    • Retype Password: If you retype the password correctly, it is set; otherwise, you need to reenter the password in both fields.

    • Clear User's Password: If a user forgets a personal password, check this box to clear the password. The user can then enter a new password at his or her discretion. In a high-security post office, it might be necessary to set a new password after clearing the old one.

    • Allow Password Caching: This option is selected by default, enabling the user to select the Remember My Password option under Tools, Options, Security in the GroupWise client. This option lets the user restart GroupWise without reentering the password. The password is stored in the Windows password list on the current computer.

    • Allow eDirectory Authentication Instead of Password: This option lets users select the No Password Required with eDirectory option under Security options in the GroupWise client. When selected, this option lets the user access his or her mailbox without requiring a password if he or she is already logged in to eDirectory. Mailbox access is granted based on eDirectory authentication, not on password information.

    • Enable Single Sign-on: This check box lets the user select the Use Novell Single Sign-on option under Tools, Options, Security in the GroupWise client. When selected, this option lets the user access his or her mailbox without reentering the password. The GroupWise password is stored in eDirectory for the currently logged-in user.

      Novell Single Sign-on must be installed on user workstations in order for this option to take effect. The Single Sign-on options are not applicable if LDAP authentication is enabled.

  • Delete GroupWise Account: This selection deletes a user's GroupWise account, but not the user's eDirectory account.

The user password portion of the user account page is a very popular destination in ConsoleOne, unless you have enabled LDAP authentication at the post office. This section listed all the ways you can approach mailbox authentication security with GroupWise.

The User Distribution Lists Property Page

To find the Distribution Lists property page, click the GroupWise tab, and click Distribution Lists. This page displays all the distribution lists that this user appears in, and it enables you to add this user to additional GroupWise distribution lists.

The Participation button enables you to specify whether the user is a TO, CC, or BC (blind copy) recipient of messages sent to the distribution list you are highlighting.

The User Internet Addressing Property Page

Internet addressing exceptions can be configured at the domain, post office, and user level. On the user object details window, this tab enables you to make exceptions at the user level. Most particularly, you can even change the USER ADDRESS portion of the USER ADDRESS@INTERNET DOMAIN NAME. This feature is new to GroupWise 6.5. Figure 5.9 shows an example in which the default Internet Addressing scheme has been changed at a user level.

Figure 5.9. Defining Internet addressing at the user level

[View full size image]

In the example shown in Figure 5.9, when Tay Kratzer sends messages to the Internet, the recipient will see Tay's address as taykratzer@wwwidgets.com. For incoming messages destined for Tay, the GroupWise Internet Agent (GWIA) will accept messages addressed to taykratzer@wwwidgets.com or tkratzer@wwwidgets.com. Because certain check marks have been removed under Allowed Address Formats, the GWIA will not allow messages sent to tay.kratzer@wwwidgets.com, kratzer.tay@wwwidgets.com, or tkratzer.corppo@wwwidgets.com.

Chapter 16 goes into depth on Internet addressing.

Note

The post office must be version 6.5 or 7 in order for you to see the "free-form" Internet address override option on the user object. The GWIA must also be version 7 for you to use this feature. This relatively new feature has many advantages when compared to the older gateway aliases (as described in the following section) in solving problems with spaces and other disallowed characters in the last name, like erno.de Korte@wwwidgets.com. The free-form Internet address filed is the preferred method for changing an Internet email address; try not to use gateway aliases anymore, which are part of an older toolset.

The User Gateway Aliases Property Page

A user alias can be used to change the "user" field for a single user's Internet address. It can also be used to change the entire address.

If you set the gateway alias address to a value with no @ sign, you are only changing the user portion of the Internet address. If you include the @ sign, you have changed the entire address for that user.

If you assign a gateway alias to a user, that alias appears as the reply-to address on all mail the user sends through that particular gateway. In an example mentioned in Chapter 3, "Understanding the GroupWise Directory," Eva Cornish wants inbound email that is addressed to webmaster@wwwidgets.com to come to her. If you create a gateway alias called "webmaster" for her, not only will she get mail addressed to "webmaster," but also all the mail she sends will appear as if it is from "webmaster." This is most likely not the desired effect. So in this scenario a gateway alias is not the best choice. It is probably better to create a nickname of "webmaster" for Eva, as covered next.

The User Nicknames Property Page

A nickname is a way for a user to exist in two places at once. It is also a way for one user to have more than one identity. Nicknames added through this tab can be placed in any GroupWise post office. This is a handy way to overcome some of the limitations of the visibility feature, and it can also enable the user to be known by more than one user ID.

Assume, for example, that Eva Cornish is the webmaster for WorldWide Widgets. If you create a nickname for Eva Cornish of "webmaster," when someone sends a message to webmaster@wwwidgets.com, it will reach Eva.

The User X.400 Information Property Page

If you need to connect your system to an X.400 system, each of your users might need an X.400-style address. In most situations, however, it is much more convenient for X.400 systems and GroupWise systems to communicate via the SMTP, or Internet email protocol.

If your users do need X.400 addresses, the X.400 system's administrator can assist you as you populate these fields.


Understanding Resource Objects

A GroupWise resource is nothing more than a mailbox used to represent a physical entity, such as a conference room or a data projector. Resources are typically used to allow GroupWise users to schedule the use of these physical entities such as a conference room in the GroupWise calendar. TheResource Identification property page, with the Identification tab displayed, is shown in Figure 5.10.

Figure 5.10. The resource object Identification property page

[View full size image]

The fields this page presents include the following:

  • Distinguished Name: This is the eDirectory name of the resource object, complete with the object's context. This field is not editable, but the resource can be moved to another eDirectory context using the eDirectory console view.

  • Post Office: This shows the GroupWise domain and post office that contain the resource. You cannot change the post office that a resource is a member of from this window. But if you go to the GroupWise view, you can right-click the resource and use the Move option. Resource moves are very similar to (and every bit as complex as) user moves. Chapter 13 talks about moving users.

  • Owner: This is the GroupWise user ID of the owner of this resource. This user is responsible for assigning proxy rights for the resource, managing the resource's calendar, and responding to mail received by the resource. All of these tasks will be performed through the GroupWise client's proxy function. The owner of the resource automatically has proxy rights to the resource object.

    A resource owner should be someone who is comfortable using GroupWise, and who has responsibility over the actual physical entity. For instance, the secretary who keeps the overhead projector at his desk should own that projector's resource object.

  • File ID: This is the three-character string that uniquely identifies this resource's USER database in this post office directory. In the example in Figure 5.10, the File ID is gqi, which means that the database for Conference Room 1 is in USERGQI.DB.

  • Description: This description field is unlike several of the others discussed in this chapter in that it is actually very useful to your user community. The text entered here will appear in the Comments field in the GroupWise address book's entry for this resource. For instance, for a conference room resource, you could populate this field with directions to the room, descriptions of the seating and white-board arrangements, and the telephone number of the individual with the key to the room.

  • Visibility: This field works exactly as it does for the user object. Restricting visibility prevents the resource from appearing in some users' address books. This is a good way to prevent users from trying to schedule a resource that they should not have access to.

  • Resource Type: There are two possible entries in this field:

    • Resource: Used to denote all types of physical objects that can be checked in or out by employees, from handheld radios to company cars.

    • Place: Used to denote conference rooms or other locations at your physical plant. When you schedule an appointment for a group of people and include a place resource, the appointment's Place field will be populated with the name of the resource.

  • Phone: If the resource is a location, such as a conference room, you can put the phone number for the conference room in this field, and it will display in the GroupWise address book. You might also put the phone number of the resource owner, particularly if the resource type is not a place.

The best thing you can do is ensure that the Identification property page is completely filled out. This will ensure that users can schedule the correct resource, and do so more quickly.

The Resource Distribution Lists Property Page

Just as in the user object details window, the Distribution Lists tab provides a list of the GroupWise distribution lists that this resource is included in. (See "The User Distribution Lists Property Page" earlier in this chapter.) The resource can be added to or removed from a mailing list using this tab.

The Resource Nicknames Property Page

The Nicknames property page also works exactly like the nicknames interface for the user object. (See "The User Nicknames Property Page" earlier in this chapter.)

The Resource Internet Addressing Property Page

Internet addressing exceptions can be configured at the domain, post office, and resource level. On the resource object details window, the Internet Addressing tab enables you to make exceptions at the resource level. Most particularly, you can even change the RESOURCE ADDRESS portion of the RESOURCE ADDRESS@INTERNET DOMAIN NAME. With the sample object shown in Figure 5.11, the resource's Internet address will be known as CONFERENCEROOM1@WWWIDGETS.COM.

Figure 5.11. The resource object Internet Addressing window

[View full size image]

If the override had not been specified, the resource's Internet address would have been CONFERENCE_ROOM_1@WWWIDGETS.COM.

Or worse yet, if the default Internet addressing scheme for the GroupWise system were FIRST.LAST@INTERNET DOMAIN, the default Internet address for the Conference Room would be CONFERENCE_ROOM_1.CONFERENCE_ROOM_1@WWWIDGETS.COM.


The Distribution List Object

The GroupWise distribution list is simply a mailing list, sometimes called a group. eDirectory group objects can also be used like GroupWise distribution lists. An eDirectory group object functions in the normal manner in which users can inherit rights. A GroupWise distribution list does not give users eDirectory rights. GroupWise distribution lists are more flexible as mailing lists than eDirectory groups, though. For example, with a GroupWise distribution list you can specify whether recipients are TO, CC, or BC recipients; with eDirectory groups you cannot.

As with every other GroupWise object, the distribution list has an Identification window in ConsoleOne. (See Figure 5.12.)

Figure 5.12. The distribution list object properties window

[View full size image]

The Distribution List Identification Property Page

As shown in Figure 5.12, this page has only a few fields to examine:

  • Distinguished Name: This is the eDirectory name and context for this distribution list object.

  • Post Office: This is the name of the GroupWise domain and post office that contains this distribution list. This field cannot be edited.

  • Description: This field appears in the GroupWise address book, and it might therefore be very helpful to your users. Distribution list descriptions can explain the purpose of the mailing list, and even whom to contact to change the membership list.

  • Visibility: Distribution list visibility, although populated with the same values as the visibility for users and resources, works a little bit differently. If you know the GroupWise address of a user, you can send mail to that user even though the user does not show up in the address book. A distribution list cannot be sent to in this way, unless you use the Replication Override field, which is explained just a little later.

    The Visibility field is extremely useful for preventing unauthorized users from using a single distribution list to send to the entire company. Simply restrict the visibility to Post Office, and only users on the same post office as the distribution list can send to the list.

  • Replication Override: By default, a distribution list cannot be sent to unless it is visible in a user's address book. However, let's say you don't want a group to be visible beyond the post office it is on, but you would like to allow users who are aware of the distribution list's name to be able to send to the distribution list. You could do this by setting the Visibility of the group to Post Office, and setting the Replication Override to Replicate Everywhere Regardless of Visibility.

Distribution lists are a powerful means of communicating to a lot of people. Just make sure you've configured them correctly so that they are not abused within your GroupWise system.

The Distribution List Internet Addressing Property Page

The Internet address of a distribution list is not visible to users outside the GroupWise system. However, if on the GWIA you have the Expand Groups on Incoming Messages option enabled, this dialog box helps you define the name of the distribution list. Generally it is not recommended that you enable this option. The ramification of having this feature enabled is that senders on the Internet can potentially flood your system with email.

The Distribution List Membership Property Page

From the Membership property page you can see all the users currently associated to a distribution list and make changes to the list. Figure 5.13 shows the interface you use to change a distribution list.

Figure 5.13. The distribution list Membership property page

[View full size image]

Clicking the Add button gives you a browser dialog box from which you can add users to a list. The Participation button enables you to change a user's participation in the list from TO to CC or even BC. The Delete button removes the selected user or users from the distribution list.

As with almost all details window operations, membership changes are not committed to the domain database until the details window is dismissed with the OK button.

The Distribution List Nicknames Property Page

A nickname on a distribution list allows the distribution list to be sent to using a different name than the distribution list's actual name.


Summary

This chapter focused on the GroupWise view and GroupWise object interfaces. Each of the objects has a different purpose, and each identification window is a little different; but they all work in much the same way.

A large portion of your time as a GroupWise system administrator will be spent working with the objects described in this chapter.


Chapter 6. Using GroupWise System Operations

System operations can potentially affect all other domains or post offices in a GroupWise system. Because of this you must have eDirectory object rights in order to access all the menu choices from the GroupWise system operations menu. If your organization has several people who administer the GroupWise system from different domains, you might want to consider who should have eDirectory object rights to the primary domain, and thus have access to all the GroupWise system operations menu choices.


Accessing System Operations

Selecting GroupWise System Operations from the Tools menu will present the menu shown in Figure 6.1.

Figure 6.1. The GroupWise System Operations menu

[View full size image]

These operations all have one thing in common: They affect GroupWise objects system-wide (the only menu option that does not affect all domains is the Select Domain menu option). This means they can affect multiple domains, post offices, and users, and it is important to know what is being done before you experiment. These operations will be discussed in turn.


Changing Connections with Select Domain

The GroupWise System Connection window, which comes up when you select Tools, GroupWise System Operations, Select Domain, enables you to change ConsoleOne's connection to a different GroupWise domain's WPDOMAIN.DB file, or even to a completely different GroupWise system.

This "connection" is simply the GroupWise domain database that ConsoleOne is reading from and writing to. This window shows the path for the domain to which ConsoleOne is currently connected.

Some administrative operations are best performed from the primary domain. When you're performing system operations, it is best to be connected to the system's primary domain. When adding users to a secondary domain, however, you might want to be connected to the domain to which the user will belong; the Select Domain window offers this flexibility.

Tip

You can also change the domain connection by right-clicking the desired domain in the GroupWise view and selecting the Connect option. You will see that the little connector icon will now show the connection to the selected domain.


System Preferences

The window shown in Figure 6.2 enables you to set administrative preferences. From these tabs, it is possible to set preferences pertaining to user creation and other parameters.

Figure 6.2. The GroupWise Admin Preferences tab

The choices under System Preferences include these:

  • Admin Preferences: From here you can make choices for the following options:

    • Set Access Rights Automatically; When Creating a GroupWise User: By checking the box labeled When Creating a GroupWise User, you allow ConsoleOne to make trustee assignments automatically for new users. These assignments include rights to the Post Office (PO) and Post Office Agent (POA) objects hosting the user's mailbox, as well as file-system rights if you are using direct access mode (which should not be done, as discussed in Chapter 5, "Working with GroupWise Objects"). If the post office is set to allow only client/server connections, the GroupWise client always chooses a client/server connection, even if the user has file-system rights. The problem with choosing this is that users could have file-system rights to places where they don't need it. As a general rule, don't check this option.

    • When Creating or Modifying Objects, for Network ID Use: The two options here apply only to objects created after this preference has been set. To modify the network ID for existing GroupWise users, open their user object and make the change. Any modification will dothe network ID will be changed in the background. Do not change this option unless you really know what you are doing. It is generally best to keep the setting at Full Distinguished Name.

    • Full Distinguished Name: The GroupWise post office records the fully distinguished eDirectory name for users, and it associates that name with the appropriate GroupWise user ID. Use this setting on post offices whose users authenticate to eDirectory.

    • Common Name: The GroupWise post office records only the common name for users, and it associates that name with the appropriate GroupWise user ID. Use this setting for post offices whose users do not authenticate to eDirectory. (Generally, the Common Name selection need not be used.)

  • Routing Options: This enables you to specify a default routing domain. Chapter 16, "Internet Addressing," provides a full discussion of how to use this option. Figure 6.3 shows the Routing Options tab.

    Figure 6.3. The Routing Options tab

  • External Access Rights: The GroupWise MTA can be enabled to send messages across the Internet to another GroupWise system. This way, GroupWise messages can retain their native GroupWise format. This feature was introduced in GroupWise 5.5. The only flaw to this feature was that in GroupWise 5.5, with MTA to MTA connectivity, outside Internet users could do busy searches and status tracking even if you did not want to allow for that. This system preference was created to control that situation. Figure 6.4 shows the External Access Rights tab.

    Figure 6.4. The External Access Rights tab

  • Nickname Settings: This feature, shown in Figure 6.5, can be helpful, particularly when you're moving a lot of people. When you move a user to a new post office, under certain circumstances or with older GroupWise clients, users might send a message to the user at their old post office location. Without a nickname tied to the old post office, the sender might get a D101 - User not found error, because the user is no longer on the old post office. However, with a nickname in place, the message will be redirected to the new place where the user resides.

    Figure 6.5. The Nickname Settings tab

    • Auto-Create on User Move: Choose whether nicknames are to be created automatically, and whether it is necessary to be prompted.

    • Expire After: Nicknames do not need to be in place forever; generally the fact that a user has moved will replicate everywhere within time. Choose a time that seems acceptable for the environment. Take into account how often caching or remote users update their copies of the system address book.

  • Default Password: By choosing a default password, as shown in Figure 6.6, you know that users immediately have a GroupWise password. GroupWise WebAccess requires that all users have a password, so having a default password is particularly attractive to those sites with users who use only WebAccess. If LDAP authentication is enabled, this password will not be in effect, but the eDirectory (or other LDAP directory) password will be the authentication password. LDAP authentication works only for users who have an account in your directory; LDAP does not work for users who are external entities.

    Figure 6.6. The Default Password tab

  • Admin Lockout Settings: This tab is shown in Figure 6.7.

    Figure 6.7. The Admin Lockout Settings tab

From here, you can configure the following:

  • Restrict System Operations to Primary Domain: If you have a GroupWise Administrator that is responsible for some secondary GroupWise domains, but do not want him or her to make system-level changes, this feature makes that possible. If Restrict System Operations to Primary Domain is enabled, when anyone is connected to a secondary domain, the only options available are Select Domain, Pending Operations, Software Directory Management, and Restore Area Management.

    Note

    The GroupWise Administration developers can change what this setting allows in the future. The ramifications of this setting can change based on the GroupWise Support Pack you are using. GroupWise 6.5 and GroupWise 7 snap-ins support this feature.

  • Lock Out Older GroupWise Administration Snapins: This setting is available only in GroupWise 6.5 Support Pack 1 or later snap-ins. You can force all administrators with older GroupWise snap-ins to upgrade, or they will not be able to use the GroupWise snap-ins to ConsoleOne. You can choose the date or the revision of the GroupWise 7 snap-ins. An example of a revision is 7.0.0.

    Figure 6.8 shows the effects on the GroupWise System Operations menu when this option is used.

    Figure 6.8. System operations are grayed out

Note

This setting is not enforced if an administrator is using NWAdmin with GroupWise 5.5x snap-ins installed or ConsoleOne with the GroupWise 6.0x snap-ins. It is honored only when ConsoleOne has GroupWise 6.5.1 snap-ins or greater installed.

There are two other system-level operations not on the GroupWise System Operations menu that are also restricted when Restrict System Operations to Primary Domain is enabled. They are scheduled events. Scheduled events are configurable under the message transfer agent (MTA) and the POA. These scheduled events will be grayed out for a secondary domain administrator. Chapter 8, "Configuring the Post Office Agent," and Chapter 9, "Configuring the Message Transfer Agent," talk about scheduled events.


eDirectory User Synchronization

eDirectory user synchronization is a process by which information is pulled from eDirectory into the GroupWise directory. Ordinarily, it is not necessary to set this preference. When ConsoleOne is run with the GroupWise snap-ins, changes are written to both directories simultaneously.

Suppose, however, that the administrators in human resources do not have file-system rights to a GroupWise domain database. They can change phone numbers, mail-stops, or titles for users, and the changes will never propagate into the GroupWise address book where they will be really usefulunless eDirectory user synchronization is correctly configured. Furthermore, if you were to create admin-defined fieldswhich is discussed just a little later in this chapterenabling eDirectory user synchronization is particularly valuable.

By default, eDirectory user synchronization is not enabled. To change the eDirectory synchronization status, click Configure Agents, which will bring up the box shown in Figure 6.9.

Figure 6.9. The Configure Agents window

[View full size image]

This window displays every MTA object in the GroupWise system. The state of each agent is either Enabled or Disabled. Before an agent can be enabled as an eDirectory Sync agent, it must have rights to read information from eDirectory.

Clicking Set Up eDirectory Access gives the highlighted MTA object the necessary trustee assignments to authenticate to and read from eDirectory. Before the rights are effective, however, the agent must be restarted.

With one or more agents enabled for eDirectory sync, you can make agent assignments. From the eDirectory User Synchronization Configuration window, highlight a domain and click Change Assignment.

Tip

It is interesting to note that an MTA can perform synchronization for more than one domain. Configuring an MTA this way can result in unnecessary GroupWise administration traffic. Novell recommends that every MTA be assigned to perform eDirectory synchronization for the domain to which it belongs, unless it is not possible for that MTA to authenticate to eDirectory for some reason.

Two more things must be configured before eDirectory user synchronization can occur. An event must be activated under the MTA's Scheduled Events tab. Chapter 9 talks about the eDirectory user synchronization event in more detail.


Creating a Custom eDirectory Attribute and Using Admin-Defined Fields

The Admin-Defined Fields tool is part of a solution that enables you to define new fields for the GroupWise address book. Extending the schema of the GroupWise and eDirectory directories does this. You can also access this tool by clicking Map Additional Fields from the Address Book tab of the domain object's details window. This section explains the entire process to take in order to add a new Address Book field that can be viewed within the GroupWise client's address book.

Tip

When making changes to eDirectory, be prepared for a possible time lag that comes with creating new attributes.

In this scenario, the administrator wants to add a field called Employee Cost Center Number, which will be viewable in the GroupWise Address Book. Here are the steps required:

Note

This procedure was written using eDirectory 8.7.3.2 and ConsoleOne 1.3.6 with the GroupWise 7 Administration Snap-ins to ConsoleOne.

1. | Make sure you are logged into Novell eDirectory as a user with rights to extend the eDirectory tree.
2. | Load ConsoleOne.
3. | Highlight an eDirectory Organization or Organizational Unit, and select Tools, Schema Manager.
4. | Select the Attributes tab.
5. | Click the Create button, and click the Next button.
6. | Name the attribute. Click the Help button for helpful information about naming this field. In this example, the name of the attribute is www: emp cost center.

Note

The assigned name cannot be more than 32 characters. That's part of the reason for a somewhat-cryptic name. Also, the www: portion of the attribute name is added so that World Wide Widgets eDirectory administrators know that this is a custom attribute added by an internal eDirectory administrator.

Figure 6.10 shows the attribute name. Click Next to define the syntax of the attribute.

Figure 6.10. Naming a new attribute

[View full size image]

7.
In the Syntax window, select Case Ignore String in the drop-down list, and click the Next button.

8.
From the Set Flags screen, select Single Valued; keep all other check boxes unchecked (unless there is a special purpose for checking them). Click the Next button.

Warning

You are about to modify the schema of your Novell eDirectory tree. Make sure that before you do so you have your syntax and naming correct. Schema reversals to Novell eDirectory are virtually impossible.

9.
From the summary screen, review the selections and click the Finish button.

10.
Exit the Schema Manager.

11.
Go back into the Schema Manager by selecting Tools, Schema Manager.

12.
From the Classes column, select the object type of Person. Click the Info button. You should see a window similar to the one shown in Figure 6.11.

Figure 6.11. Adding an attribute to the person object

[View full size image]

13.
Click the Add Attribute button.

14.
From the Available Attributes column in the Add Optional Attribute window, scroll down to the attribute created earlier. In the sample scenario this is the www: emp cost center number attribute. With the attribute highlighted, select the arrow pointing to the right, which places the attribute in the Add These Attributes column. Figure 6.12 shows that the attribute www: emp cost center number has been added to the person object.

Figure 6.12. Selecting the attribute

[View full size image]

15.
Click the OK button and then close out of the Schema Manager utility.

16.
In ConsoleOne, go to the GroupWise view. Make sure that you are connected to the GroupWise primary domain.

17.
Select Tools, GroupWise System Operations, Admin Defined Fields.

18.
From the Administrator-Defined Fields window, highlight an unused admin-defined field, and then click the Edit button.

Warning

You are about to permanently modify the contents of your GroupWise system. After you have created an admin-defined field, it is not reversible. The snap-ins seem to give you a sense that you can clear an admin-defined field, but in my own testing, this is not the case. After you have used an admin-defined field, you cannot get other information to populate to that admin-defined field. When creating a new admin-defined field, in order for things to be successful, you must use an admin-defined field that you have never used before. So if you have used Admin Defined 1 already, even if you have cleared it out, it is best to now use Admin Defined 2.

19.
From the Select eDirectory User Property window, select the attribute www: emp cost center number, and click the OK button. You should see the attribute mapped to an admin-defined field as shown in Figure 6.13. Click the OK button to dismiss the Administrator-Defined Fields utility.

Figure 6.13. Assigning an eDirectory attribute to an admin-defined field

To add admin-defined fields to the address book of a post office, you must define the attribute to the domain that owns that post office. Therefore, the steps described going forward must be performed on every GroupWise domain.

20.
Highlight the domain containing post offices whose address book you want to display this new field in.

21.
Edit the domain by right-clicking it and selecting the Properties menu option.

22.
On the GroupWise tab from the Properties of the domain, select the address book property page.

23.
From the Available Fields column, select www: emp cost center number and click the arrow pointing to the left. This adds www: emp cost center number to the Address Book Fields column.

24.
With the www: emp cost center number attribute highlighted in the Address Book Fields column, click the Edit Label button.

25.
In the Address Book Label field, give the field a more intelligible name; this name is the name users will see within their GroupWise client. Then click the OK button. Figure 6.14 shows a fully configured Address Book field.

Figure 6.14. Configuring the address book to contain an admin-defined field

[View full size image]

26.
Assign the Employee Cost Center Number to a user. The instructions given here are instructions for how to populate the attributes for one user. If you had a mechanism for bulk loading the newly created eDirectory field, it could be used as well. You must, however, have eDirectory User Synchronization enabled to ensure that the GroupWise Domain MTA replicates to the GroupWise directory the information that was put into eDirectory. When populating the www: emp cost center number field for a user, you do so with the GroupWise snap-ins to ConsoleOne installed. The GroupWise Administration snap-ins know to grab the contents of the www: emp cost center number field and add it to the GroupWise Address Book as the field called Employee Cost Center Number. If you bulk load information into eDirectory, however, there's not necessarily a mechanism to determine that the information in eDirectory then gets populated over to the GroupWise directory (WDOMAIN.DB and WPHOST.DB files). With eDirectory User Synchronization enabled and configured, the GroupWise MTA will extract the values from the eDirectory field www: emp cost center number and push it into the GroupWise directory into the GroupWise Employee Cost Center Number field.

27.
Edit the properties for a user object that is on a post office configured to allow the new Employee Cost Center Number attribute to be displayed in the address book.

28.
Go to the Other tab on the user object.

29.
Select the word Attributes and then click the Add button.

30.
Find the attribute www: emp cost center number from the list of available attributes, and click the OK button.

31.
Populate the entry field below the new attribute, and click the Apply button.You can now log in to GroupWise as a member of the post office that allows for the addition of Address Book fields, and view the user. To do this, run the GroupWise 6.5 or 7 client and go into the address book. Select the user, and select View, Details. You should see something similar to what's shown in Figure 6.15.

Figure 6.15. Viewing details on a user with a custom attribute

[View full size image]


Creating a Mobile Phone Entry in the GroupWise Address Book

This is a solution that enables you to define new fields for the GroupWise address book. Extending the schema of the GroupWise directory does this. To take the mobile attribute in eDirectory and map it to a new Address Book field that can be viewed within the GroupWise client's address book, follow these steps:

Note

This procedure was written using eDirectory 8.7.3.2 and ConsoleOne 1.3.6 with the GroupWise 7 Administration Snap-ins to ConsoleOne.

1.
In ConsoleOne, go to the GroupWise view. Make sure that you are connected to the GroupWise primary domain.

2.
Select Tools, GroupWise System Operations, Admin Defined Fields.

3.
From the Administrator-Defined Fields window, highlight an unused admin-defined field, and then click the Edit button.

Warning

You are about to permanently modify the contents of your GroupWise system. After you have created an admin-defined field, it is not reversible. The snap-ins seem to give you a sense that you can clear an admin-defined field, but in my own testing, this is not the case. After you have used an admin-defined field, you cannot get other information to populate to that admin-defined field. When creating a new admin-defined field, in order for things to be successful, you must use an admin-defined field that you have never used before. So if you have used Admin Defined 1 already, even if you have cleared it out, it is best to now use Admin Defined 2.

4.
From the Select eDirectory User Property window, select the attribute mobile, and click the OK button. You should see the attribute mapped to an admin-defined field. Click the OK button to dismiss the Admin-Defined Fields utility.

To add admin-defined fields to the address book of a post office, you must define the attribute to the domain that owns that post office. Therefore, the steps described going forward must be performed on every GroupWise domain.

5.
Highlight the domain containing post offices whose address book you want to display this new field in.

6.
Edit the domain by right-clicking it and selecting the Properties menu option.

7.
On the GroupWise tab from the Properties of the domain, select the address book property page.

8.
From the Available Fields column, select mobile and click the arrow pointing to the left. This adds mobile to the Address Book Fields column.

9.
With the mobile attribute highlighted in the Address Book Fields column, click the Edit Label button.

10.
In the Address Book Label field, give the field a more intelligible name; this name is the name users will see within their GroupWise clientfor example, Mobile Phone. Then click the OK button.

Assign the Mobile Phone number to a user. The instructions given here are instructions for how to populate the attributes for one user. If you had a mechanism for bulk loading the mobile attribute in eDirectory, it could be used as well. You must, however, have eDirectory User Synchronization enabled to ensure that the GroupWise Domain MTA replicates to the GroupWise directory the information that was put into eDirectory. When populating the mobile field for a user, you do so with the GroupWise snap-ins to ConsoleOne installed. The GroupWise Administration snap-ins know to grab the contents of the mobile field and add it to the GroupWise Address Book as the field called Employee Cost Center Number. If you bulk load information into eDirectory, however, there's not necessarily a mechanism to determine that the information in eDirectory then gets populated over to the GroupWise directory (WDOMAIN.DB and WPHOST.DB files). With eDirectory User Synchronization enabled and configured, the GroupWise MTA will extract the values from the eDirectory field mobile and push it into the GroupWise directory into the Mobile Phone field.

11.
Edit the properties for a user object that is on a post office off of a domain configured to allow the Mobile Phone attribute to be displayed in the address book.

12.
Go to the Other tab on the user object.

13.
Select the word Attributes and then click the Add button.

14.
Find the attribute mobile from the list of available attributes, and click the OK button.

15.
Populate the entry field below the new attribute, and click the Apply button.

16.
Log in to GroupWise as a member of the post office that allows for the addition of Address Book fields, and view the user. To do this, run the GroupWise 6.5 or 7 client and go into the address book. Select the user, and select View, Details. You should see something similar to what's shown in Figure 6.16.

Figure 6.16. Viewing details on a user with the Mobile Phone attribute populated

[View full size image]

Note

After you have used admin-defined fields, if a user does not have a value filled in on the admin-defined field, you will not see the field at all.

Although the steps to configure admin-defined fields are many, after you have it all configured, you have a powerful way to add eDirectory information into the GroupWise address book.


Pending Operations

When changes are made that involve multiple domains, it is possible for these changes to take several minutes to complete. While connected to a particular domain, the Pending Operations box lists all operations that this domain still has marked as unsafe.

Consider an example in which a change was made to the phone number on a user that is owned by DOMAINA, but the person making the change is connected to DOMAINB. DOMAINB must wait for DOMAINA to acknowledge the change to the user whose phone number changed. Until an acknowledgment is returned to DOMAINB, the operation performed will show up in the Pending Operations box from the perspective of DOMAINB.

If you suspect synchronization problems, try using some of the buttons in this window to solve the problem. Unfortunately, this seldom works. Typically, when an operation is pending for an extended period, the problem is not a simple one. Try these actions to resolve a pending operation:

  • Undo: Restores the object record in this database to its original state and sends a request to the other domain or domains to do the same.

  • Retry: Resends the transaction request. This is likely to work only if the original request somehow got lost in transitsomething that seldom happensor if domain databases have been rebuilt to repair problems.

  • View: Displays the transaction in more detail.

  • Refresh: Rereads the list of pending operations.

You can certainly try and retry the item listed in Pending Operations. However, in my experience, you are generally better off using the Undo operation, and then redoing it, and keeping a close eye on the GroupWise agents to see whether the change goes through.


Addressing Rules

Addressing rules are find-and-replace operations that act on the addresses that users enter in the TO, CC, and BC fields in mail messages they send. This feature was introduced in earlier versions of GroupWise so that Internet-style addresses could be entered without adding a gateway prefix.

In GroupWise 4.1 and 5.2, a user sending to glennbrown@novell.com had to enter a string such as domain.smtp gateway name:tkratzer@wwwidgets.com or INTERNET:glennbrown@novell.com. With addressing rules, the prefix can now be added automatically by the system, making things simpler for the user. Configuring the addressing rules correctly is anything but simple, however.

Fortunately, from GroupWise 5.5 going forward, there is a much better alternative to using addressing rules: native Internet addressing. If you have a need for an addressing rule for other conditions, you will want to set up addressing rules for your users. For example, if your users send a message to FAX:5551212, perhaps you'll want to have the FAX: changed to GATEWAYS_DOM.GWFAX:5551212. This can be done with an addressing rule (see Figure 6.17).

Figure 6.17. The New Addressing Rule box

The following is a list of fields you fill out when defining an addressing rule:

  • Description: Enter a brief description of the rule.

  • Name: Name the rule.

  • Search String: Enter the search string that will trigger the rule.

    For example, FAX:* searches for any address that is preceded by FAX:.

  • Replace With: Enter the string to replace the address line. Be sure to include all necessary elements of the original address string, as in the following example:

    GATEWAYS_DOM.GWFAX:"%1"

  • Test Address: Enter an address that a user might enter, for testing your rule, such as the following:

    FAX:5551212

  • Results: After the Test button is clicked, this field will be populated automatically:

    GATEWAYS_DOM.GWFAX:"5551212"

Note

When you create an addressing rule from system operations, it is not enabled at the domain level yet. You must then go to the properties of the domain, and from the GroupWise tab, select the Addressing Rules option. From here, you will see all addressing rules that have been defined from system operations. You can now enable them at the domain level and they will be active. Addressing rules are activated or deactivated at a domain level only. They are created at the system level through system operations.

When Internet addressing is enabled, any addressing rule you create that contains an @ symbol in the search field, and a : in the replace field, will be ignored by any GroupWise 5.5 or newer client. The reason for this is that these types of rules were in older GroupWise systems to provide the functionality that Internet addressing now provides. These rules are no longer needed unless you still have users using a GroupWise client older than 5.5x.

Tip

Addressing rules are processed in order from top to bottom. If you have multiple addressing rules defined, be aware that the format might have been altered by a previous addressing rule by the time it is acted on by a lower addressing rule. You can rearrange the order of the addressing rules by clicking the up and down arrows.


Time Zones

In a GroupWise system with post offices in more than one time zone, it is critical that the time zones be correctly configured. If you do business via email with users on the Internet, you will also want to make sure your time zones are configured correctly so that timestamps on your email messages reflect reality.

The time zones that are predefined in GroupWise 7 should cover every real time zone on the planet. Most GroupWise shops find that after the correct time zone has been selected at the domain or post office level, timestamps system-wide are accurate.

Suppose, though, that you have a need to edit this time zone (Novell does not recommend this, but the functionality is here). Clicking Edit calls up a new dialog box in which you can edit the time zone. All aspects of the time zone are available to be edited, including the rather tricky algorithm for determining when daylight saving time begins and ends.

Numerous administrators have made a mistake using this interface. Suppose you have offices in Las Vegas and Phoenix. Las Vegas observes daylight saving time, and Phoenix does not, but both cities observe the same offset from GMT. You have assigned both domains to the mountain time zone. If you connect to the Phoenix domain and edit this time zone (to turn daylight saving time off, of course), you are making that change system-wide. You have just turned daylight saving time off for Phoenix and for Las Vegas.

Tip

The mistake was a simple one, and the solution is equally simple. Don't edit time zones. Put Phoenix in a different time zone than Las Vegas. There is even a predefined time zone, Arizona, that suits your needs perfectly in this case. Remember, you are performing system operations in this chapterif you edit a time zone, you do so for the whole system.

Warning

Do not edit time zones unless you really intend to do so. Editing time zones affects any other entities in the time zone that you edited.


External System Synchronization

If your organization has partners that use GroupWise, you might want to synchronize your address books with theirs. This synchronization must be set up on both sides, and requires you to choose a single domain on the external system as your point-of-contact.

When configured correctly, external system synchronization is a powerful collaborative tool. Users in your organization will see members of the external system as entries in the Novell GroupWise address book and can communicate and share with those users just as they do with users on their home system. The process of defining an external system, and then synchronizing with that external system, is fully explained in Chapter 15, "Administering Multiple GroupWise Systems."


Software Directory Management

The software directory management feature (see Figure 6.18, shown just a bit later) is a powerful tool. A Software Distribution Directory object represents a directory on a file server that contains GroupWise software. These objects can be assigned to post offices, but each post office can be assigned to only one Software Distribution Directory.

Figure 6.18. Defining a Software Distribution Directory

Your scheme for managing software distribution directories can have a huge impact on your successful rollout of the GroupWise client, or on upgrading the GroupWise client. Chapter 12, "Administering the GroupWise Client," goes into a significant amount of detail on leveraging the software distribution directories to your advantage.

There are several things you might want to do with software distribution directories as part of your GroupWise administration:

  • Create a new directory

  • Move an existing directory to a new path

  • Patch or update an existing directory

  • Delete an existing directory

Creating a Software Distribution Directory is straightforward. Chapter 12 will give you a better understanding as to why you should create a Software Distribution Directory.

Creating New Software Distribution Directories

Clicking the Create button from the Software Distribution Directory Management window results in the dialog box shown in Figure 6.18. Software distribution directories describe a directory that typically exists. When you first installed GroupWise 7, you most likely established a Software Distribution Directory (SDD). The purpose for defining an SDD is to associate the SDD to post offices so that the users of that post office can update their GroupWise clients when upgrades happen.

The following are the fields you fill in when defining a Software Distribution Directory:

  • Name: You must assign a unique name to each Software Distribution Directory object. You might choose to name the object based on the server on which it will reside.

  • Description: This optional field can be populated with the name and number of the individual responsible for maintaining the software in this directory. Input a detailed description. This description is used when assigning a Software Distribution Directory to a GroupWise post office.

  • UNC Path: This is the path to the directory. If a drive has been mapped already, you can browse to the directory. The field will be populated with a drive-based path, but when you click OK, GroupWise administrator converts that path to UNC format.

  • AppleTalk Path: Only users of the GroupWise 5.2 Macintosh client who cannot browse to UNC paths will use this optional path.

  • Linux Path: This is the path to a Software Distribution Directory on a Linux server. This should not be a UNC path from a SAMBA mount. This should be a path such as /data/gw70sdd.

  • Copy Software From: If you check this box, you're indicating that you want to populate the UNC path that you specified from another Software Distribution Directory. If you do not already have a GroupWise 7 Software Distribution Directory, run SETUP.EXE from the GroupWise 7 Administration CD to create one.

Note

The process responsible for this copy operation is ConsoleOne, running on your workstation. It might not be wise to use this feature to populate software distribution directories across a wide area network (WAN). In these cases, you should not use the Copy software from this feature. Instead, have someone local to that server manually copy the GroupWise 7 Admin & Client software from CDs into the directory you specified.

Editing or Moving Existing Directories

Moving a Software Distribution Directory is simple, and is accomplished by following these two steps:

1. | Using Explorer or a command prompt, move or copy the software from the current location to the new location.
2. | Edit your existing Software Distribution Directory and change the UNC Path field and the Name field, if needed.

Note

Be careful about editing SDDs; this causes a number called the bump number to be incremented on all post offices that point to this defined SDD. This could cause users to start receiving prompts that there is new GroupWise software available. You'll find more about this subject in Chapter 12.

Deleting Existing Directories

The Software Distribution Directory Management window can be used to delete the SDD object, but the directory itself must be deleted manually. This action prevents accidental deletion of software in cases in which SDD objects share physical directories.

Patching or Updating Existing Directories

The Update tool (shown in Figure 6.19) is used only after a patch or an upgrade has been applied to an SDD somewhere on the system. For instructions regarding applying patches, refer to the readme file or files associated with that particular patch.

Figure 6.19. The Update Software Distribution Directory dialog box

After one directory on the system has been updated, you can use this interface to copy the updated files from the updated directory to other directories.

Note

Again, be careful about using this to distribute software across the WAN. It is probably a wiser use of bandwidth to patch or update a remote SDD while on location.

The Force Auto-Update Check by GroupWise Components check box exists to alert the GroupWise client that new software is available. When you check this box and click OK, the new software bump number associated with this SDD is incremented by one. Therefore, this is not something to be undertaken lightly! Every GroupWise client that attaches to any post office assigned to this SDD must browse to the UNC path and determine whether the code in the directory is newer than the code on the user's workstation. If the UNC path is not available (that is, the user has no rights to the directory), and SETUPIP is not configured, an error will be reported.

This subject, along with SETUPIP, is covered in Chapter 12.


Using Restore Area Management

A restore area is a location where a post office has been restored from backup. There's no set procedure on how you configure restore areas. You might want to create one per post office. Or you can just create restore areas on demand. When there's a need to restore something, and you've restored a post office from backup, you come here to define a restore area.

The following are the fields available in the Restore Area Management configuration window:

  • Restore Area Directories: Displays the directories in your GroupWise system that have been designated as restore areas for post offices.

  • Description: Select a restore area directory to display any information entered in the Description field when the restore area was created. To modify or add a description, click Edit.

  • Create: To create a restore area, click Create. You can create multiple restore areas.

  • Edit: Select a restore area directory and then click Edit to modify the name, description, or location of the restore area.

  • Delete: Select a restore area directory and then click Delete to delete the restore area.

Figure 6.20 shows the window for Restore Area Management and a sample restore area. Restore areas are part of a backup and restore system that is fully explained in Chapter 28, "Restoring Deleted Users."

Figure 6.20. Restore area directory management

Previous Page
Next Page


Internet Addressing

Since the early 1990s, GroupWise has used a proprietary addressing format, commonly called UPD format for User.PostOffice.Domain. With GroupWise 5.5, Novell made it possible for the administrator to change the internal addressing algorithms. GroupWise 6.5 and GroupWise 7 can be configured to use Internet-style addresses.

Because of the significant impact of this change, there's an entire chapter devoted to Internet addressing. Refer to Chapter 16 for more information.


Trusted Applications

Trusted applications are a new feature to GroupWise 6.5 and 7. A trusted application is not something you create in ConsoleOne, nor is it configured from ConsoleOne. A trusted application is an object that is created by software that might integrate with GroupWise. An example might be GWAVA's (www.beginfinite.com) post office message store scanning features (shown in Figure 6.21). There is one other place where you can disable certain trusted applications. If you edit a post office, and select the Post Office Settings property page, you have the option to Exempt This Post Office from the Trusted Application Routing Requirement.

Figure 6.21. GWAVA as a trusted application

Because a trusted application is really a registry for a third-party software solution of some type, consult the documentation for that software for configuration procedures.


LDAP Servers

LDAP authentication servers can be configured from ConsoleOne. With LDAP authentication there are some distinct advantages, including these:

  • Users no longer need to remember an eDirectory and a GroupWise password.

  • Even if users use GroupWise WebAccess or GroupWise Wireless, their passwords will be the same as their eDirectory passwords.

  • When users change their password in GroupWise, it can also change their eDirectory passwords.

  • Password expiration in GroupWise is now feasible because it's really just an eDirectory password.

The process of creating LDAP servers should be well thought out and well configured. Because of this, we've dedicated an entire chapter (Chapter 26, "Configuring GroupWise Authentication via LDAP") to configuring GroupWise authentication via LDAP.


Global Signatures

This feature is new to GroupWise 7. A Global Signature is a static set of text that can be inserted at the end of users' emails. Global Signatures are not necessarily "Global" in nature, in that they can be enabled more granularly than that. For example, you could create a Global Signature that is used by only one post office. Global Signatures are defined as a system record, under System Operations, and are then enabled in Client Options in ConsoleOne.

Following are the steps for creating a Global Signature under System Operations. After clicking the Create button, do the following:

  • Name: You must assign a unique name to the Global Signaturefor example, SIG-Legal-Disclaimer.

  • Font: You can indicate the font that should be used; however, realize that the fonts shown are all the fonts installed on the Windows PC where GroupWise administration is installed. It may be best to choose a font such as Monospaced.

  • Signature Body: Type in the contents of the signature, as shown in Figure 6.22.

    Figure 6.22. A Global Signature

    [View full size image]


Summary

This chapter explored how to use a number of tools that apply changes to your entire GroupWise system. Now that you are familiar with each of them, it is time to move to the GroupWise utilities, which is the topic of Chapter 7, "GroupWise Utilities and Diagnostics."


Chapter 7. GroupWise Utilities and Diagnostics

Even though this is the seventh chapter of the book, there are still quite a few GroupWise administration tools that need to be introduced. This chapter discusses the GroupWise Utilities menu and the functionality it presents. This chapter also discusses the GroupWise diagnostics.


The GroupWise Utilities Menu

Much of the work performed in administering the GroupWise system is done from the GroupWise Utilities menu, shown in Figure 7.1. On this menu are the tools used to maintain and repair libraries and user mailboxes, set global defaults for users' GroupWise client preferences, define links between GroupWise servers, and more.

Figure 7.1. The GroupWise Utilities menu

[View full size image]

Note

The GroupWise Utilities menu is context-sensitive. The available menu items change depending on which view is active and what type of object has been selected.

For some of the options on the GroupWise Utilities menu, this chapter gives only a brief description, because these utilities are discussed in other chapters.

Mailbox/Library Maintenance

The Mailbox/Library Maintenance menu item brings up the tools used to repair the GroupWise information store. Mailbox/Library Maintenance is just another name for the GroupWise check utility, or GWCHECK. When you issue a Mailbox/Library Maintenance job from ConsoleOne, the selections you make are sent to the Post Office Agent (POA) for the selected post office. The POA then runs the job using the GWCHECK code, which is embedded in the POA. In Chapter 17, "Maintaining the GroupWise System," Mailbox/Library Maintenance is covered in more detail.

Note

There is also a Windows and Linux-based utility called GWCHECK that can do almost the same tasks as we describe in this chapter. This tool is described in Chapter 17. However, we prefer to use the server-based GWCHECK because of the speed and the certainty that the check and fix will not be hindered by file locks.

System Maintenance

The System Maintenance menu item brings up the tools for the repair of the GroupWise directory domain and post office databases. Chapter 17 gives practical circumstances under which to use System Maintenance.

Backup/Restore Mailbox

The Backup/Restore Mailbox menu item is a piece of the Smart Purge and Backup/Restore system. This feature enables you to manually specify that a post office's user databases have been backed up, and to add a backup timestamp into the user databases. Selecting this menu option, and selecting Backup or Restore, will send a message to the POA to complete this function. Chapter 28, "Restoring Deleted Users," contains a thorough explanation of how to use this Backup/Restore Mailbox, along with other features related to the Backup/Restore Mailbox.

Recover Deleted Account

If a use r has been deleted accidentally, the user's user object can be added back to the WPDOMAIN.DB and eDirectory with all the original information. Most important, the user retains his or her FID, which is a three-character identifier, and his or her GUID (globally unique identifier), which is another unique identifier that is particularly important with document management in GroupWise. To use this utility you must have a backup of the primary domain's WPDOMAIN.DB file. Do the following to recover a deleted account:

1. | Select the Recover Deleted Account menu item.
2. | Click the Browse button next to the Backup Domain Path field and select WPDOMAIN.DB for the primary domain, which you have brought back from backup. The WPDOMAIN.DB file must be from a time before the user was deleted.
3. | Click the Browser button next to the Account to Restore field, filter for the user, and then select the user. Proceed through the rest of the Recover Deleted Account Wizard.

Note

Restoring a user's object won't bring back his or her mail. Further steps must be taken to restore the user's mail messages. Chapter 28 goes into detail on how to restore a user's mailbox. Here are a couple of field notes on this feature: We've had this feature work several times, and fail a few times. So you might need to use the Import/Export feature to restore a user. This is also explained in Chapter 28. We've been able to use the Recover Deleted Account feature when specifying the path to a secondary domain's WPDOMAIN.DB, so although the instructions say to use the primary domain, in our experience a secondary domain works fine as well.

Client Options

Figure 7.2 shows that the Client Options window looks very similar to the interface found under the Tools, Options interface in the 32-bit GroupWise client. Settings here can be made and specified as defaults or even locked down as defaults for users, post offices, and entire domains.

Figure 7.2. The GroupWise Client Options dialog box in ConsoleOne

Note

As a general rule, it is best to allow most client options to stay at the system default. When you have a specific business need to make the GroupWise client, or GroupWise mailboxes, behave in a certain manner, you will want to utilize the Client Options features.

Double-clicking the Environment button causes the dialog box shown in Figure 7.3 to appear.

Figure 7.3. Administering GroupWise client environment options in ConsoleOne

Previous Page
Next Page


Client Environment Options

The dialog box shown in Figure 7.3 looks somewhat similar to the Tools, Options, Environment dialog box as seen from the GroupWise 32-bit Windows client. Imagine, for example, that you did not want the users' mailboxes to refresh every minute, but instead every two minutes by default. Changing the Refresh Interval to a value of 2 would accomplish your design. Users can change this back to 1 or to 3 or whatever else they like. Take note, however, of the set of padlock buttons on the right side. To make sure that the users' mailboxes refresh only every two minutes, you can set the padlock button, which locks this setting so that users cannot make changes.

Tip

Client options can be set, and/or locked, on a user, post office, or domain level. If you want to set an option on an entire post office, be sure to highlight that post office, and then choose Tools, GroupWise Utilities, Client Options. If you want to set the client options for an entire domain, highlight the domain object, and then choose Tools, GroupWise Utilities, Client Options.

Any setting listed in this dialog box can be changed, which will effectively change the default options for users who have not changed their defaults. Clicking the adjacent padlock puts a locked setting in place. This will prevent users from changing their individual default, and it will also force the setting down to users who might have already changed it. If a user were to view these settings after the administrator has locked them down, they would be grayed out, and the user would not be able to modify them.

Note

You can lock client options on a user, post office, or domain level. However, if you lock them at the domain or post office level, you cannot change them anymore on a user level.

Some of the settings shown in Figure 7.3 are not available under Tools, Options in the GroupWise client. For example, if you uncheck the option Allow Shared Folder Creation, when a user goes to create a folder, the option to create a shared folder will be grayed out.

Note

The settings you configure in client options do not carry over for GroupWise users who are in GroupWise remote mode or GroupWise caching mode.

GeneralAllow Shared Folder Creation

This option takes away the capabilityor enables the capabilityfor users to share folders. This option should generally be enabled.

GeneralAllow Shared Address Book Creation

This option takes away the capabilityor enables the capabilityfor users to share address books. If you are using another address book solution, you should take away the capability to share address books. This will encourage users to use another address solution for sharing addresses.

GeneralCheck Spelling Before Send

This option is not enabled by default, but because good spelling is a dying art in this modern era of spell-checking computers, it might be a good idea to enable it.

GeneralShow Messenger Presence

This is a option is not enabled by default, but because good spelling is a dying art in this modern era of feature that is new to GroupWise 7, and thus requires the GroupWise 7 Messenger client in order to work. When a user is in his or her GroupWise 7 client, the GroupWise client can indicate whether a particular user is logged into his or her GroupWise Messenger client.

GeneralEnable Junk Mail Handling

By default, Junk Mail Handling is enabled; you might, however, want to consider whether your organization is going to use Junk Mail Handling or not. At its best, Junk Mail Handling is a feature that gives users the satisfaction of zapping junk mail. At its worst, users can flag thousands of junk mail addresses (spammers), only to find that they continue to get spam from differing addresses on the Internet. The impact on the GroupWise system is that whenever a user gets a message from the Internet, the POA must go through the Junk Mail Handling list to see whether the message to be received matches any of the addresses in the list. Chapter 25, "Configuring a Spam/Junk Mail Control Solution," goes into a lot more detail on how to manage junk mail and spam mail. Consult Chapter 25 further to see whether you should keep the Junk Mail features enabled.

Allow Use of POP/IMAP/NNTP Accounts in the Online Mailbox

These options are not enabled by default, which is a good idea. If you allow users to POP their mailboxes from other email accounts, they could bloat your message store beyond what you expect. The same goes for IMAP and NNTP. Generally, you will want to enable these features on a user-by-user basis. If you enable the POP/IMAP feature, your users will see the Accounts menu option right next to the Tools menu in their GroupWise client. From the Accounts menu, users can define a POP3 or IMAP server to retrieve messages from.

If NNTP is enabled, when a user goes to create a folder, one of the options on that folder will be to enable them to define NNTP-specific information.

If a user is in caching mode or remote mode, that user can access POP3, IMAP4, and NNTP accounts, even if you have locked those features down. The reason for this is that the GroupWise POA cannot exert control over a GroupWise information store that is on a user's hard drive. So these features cannot be controlled.

Client AccessClient Licensing

Under the Client Access tab shown in Figure 7.4, you will see two kinds of client licensing:

  • Full License Mailboxes: Windows/Cross Platform client access.

  • Limited License Mailboxes: NonWindows/Cross Platform client access, such as WebAccess/Wireless, POP3, and IMAP4.

Figure 7.4. The Client Access menu

Note

If you are using a client that uses the Windows or Cross Platform client to access the GroupWise message store, this is still considered a full license mailbox.

GroupWise is licensed per mailbox. However, Novell licenses the mailboxes in such a manner that there are two access methods (and two prices of mailboxes); they are Windows/Cross Platform client access or limited client access. When a mailbox is accessed via the GroupWise Windows or Cross Platform client, the mailbox is stamped in the GroupWise system as a full license mailbox. After the Windows or Cross Platform client accesses a mailbox, that mailbox is considered a full license mailbox for its life (even if you rename the user). If a user accesses a mailbox only via a limited client connection, for example Outlook Express as a POP3 client, that mailbox is considered a limited license mailbox.

The notion of the mailbox types is relevant for customers who must determine how many licenses of GroupWise they need to report to Novell or a Novell partner in order to assess the correct licensing and maintenance fees. By default, all mailboxes are considered full license mailboxes. If you were to create a new mailbox for a user you do not want to use the Windows or Cross Platform client (in an effort to decrease the cost of the mailbox), it would be wise to do the following:

1. | Create the user.
2. | In ConsoleOne, highlight the user and select Tools, GroupWise Utilities, Client Options, Environment, Client Access.
3. | Change the Client Licensing selection to limited license mailbox.

The process of determining how many of your current users are using limited license mailboxes requires a GWCHECK job, and looking at the right place to gather the information. This process is explained in Chapter 17.

Client AccessClient Login Mode

With this selection in this section of the Environment options, you can control how much flexibility GroupWise has to make copies of a user's mailbox for additional speed or functionality. GroupWise has always had a remote mode. With GroupWise 6.x and GroupWise 7, caching mode has been added. The caching mode does all that remote mode ever did, and more. The caching mode allows the GroupWise client to receive regular automatic updates to the caching mailbox, as well as keep a live connection with the GroupWise POA, which is necessary for functions such as busy search or cross-post-office proxy. Another advantage to caching mode is that the GroupWise client needs to chat far less with the GroupWise POA in order to read data from the GroupWise information store. Also, if the POA goes down for some reason, when the GroupWise client is in caching mode, the GroupWise client doesn't even blink.

Warning

The caching mode feature replicates a user's entire mailbox down to that user's local hard drive. If in your GroupWise system you do not have a message expiration policy, and the GWCHECK-Mailbox/Library Maintenance procedures to enforce the expiration policy, your users could have more data than can be contained on their local hard drive. Experience has shown that this can lead to problematic behavior of Windows computers, sometimes making it even impossible to reboot properly.

The GroupWise client can interact with the GroupWise user's mailbox when it is in one of three locations:

  • The post office (the standard GroupWise client mode)

  • A copy of the user's mailbox in remote mode

  • A copy of the user's mailbox in caching mode

If you do not want your users to use remote mode or caching mode, you can disable these modes.

Almost always, if you need your users to have remote connectivity to their mailboxes, you will want to encourage your users to use caching mode. Here are some reasons that support using caching mode. Imagine that you have a couple of users who connect over a slow WAN link to their post office. Because the caching mode is much less chatty than a normal client/server connection to the POA, you could force some users to use caching mode. To do this, highlight the individual, and then go into Tools, GroupWise Utilities, Client Options and select the check box Force "Caching" Mode After: X Days. A value of 0 means that the next time users log in they will be forced to caching mode, and they will be kept in caching mode going forward.

The feature By Default, Show Login Mode Drop-Down List on Client Toolbar is useful for this reason. If your users were previously GroupWise 5x users, they never saw the online or caching options in their GroupWise client. Rather than confusing your GroupWise 5x users, or leaving them to make the decision to go to caching mode, you can just hide this feature by unchecking this option.

The GroupWise client is capable of establishing a live remote connection with a message transfer agent (MTA). This MTA opens a link to the user's post office, and the POA accesses the user's mail.

The Views Tab

On the Views tab of the Environment Options dialog, there are several options:

  • Read Next After Accept, Decline, or Delete. Generally you want to enable this feature, because it makes browsing messages easier.

  • Open New View After Send. This feature is generally best kept unchecked, to allow users to make their own choice as to how the GroupWise client behaves.

  • Allowable Read Views. This feature is new to GroupWise 7. This allows the administrator to indicate whether a user is able to view messages in either text or HTML format. For some GroupWise customers, HTML formatting may be considered a virus threat, and as such they may want to disable viewing of HTML messages.

  • Allowable Compose Views. This feature is new to GroupWise 7. This allows the administrator to indicate whether a user is able to compose messages in either text or HTML format.

  • Disable HTML View. There are many reasons you might want to disable HTML viewing. The HTML viewing enables features from Microsoft Internet Explorer. With this design, HTML viewing could possibly enable browser-based viruses or browser-based security breaches. The downside to disabling this is that you take away a major feature that might be necessary for users to receive legitimate communication.

How users view messages is an important part of the users' productivity. Make choices that work for your environment; however, generally you do not want to lock these preferences down.

File LocationArchive Directory

From the File Location tab in the Environment Options box, GroupWise users can archive their messages to a location other than their mailbox. If there is a message expiration policy of 90 days, users who archive will have recourse for saving messages that are important enough to them to retain beyond those 90 days. It should be noted that there are some organizations that don't want, or cannot accept, the legal liability associated with archived messages. If your organization does not want users to archive, keep the path blank and click the padlock button.

Note

If your users have defined their own archive paths, and then you lock the archive path with a blank path, when the users log back in they will not be able to archive anything, nor will they have access to any previous archives.

Many organizations find they do need an archiving solution, but that solution must be centralized.

File LocationCustom Views

Custom Views is part of a somewhat obscure but useful feature in the GroupWise Windows client. If a user has a standard message, or even a template message that he or she often sends, that user can save that message in the form of a "custom view" file. The File Location tab simply indicates where custom views should be saved and retrieved by default.

Cleanup

In the Cleanup tab in the Environment Options box, you can specify just how mail messages should be cleaned up. The options in this tab can be useful for implementing a message retention policy. Using Mailbox/Library Maintenance jobs (GWCHECK) is a more effective method for implementing a message retention policy. All the cleanup options set here, except the archive options, are performed by the POA during a process called nightly user upkeep (nightly user upkeep is enabled by default on the POA). If the auto-archive feature has been selected, the archiving operation takes place when the GroupWise client logs in each day. The client must do the archiving because the POA usually does not have rights or even access to the user's archive path.

CleanupAllow Purge of Items Not Backed Up

With GroupWise 6.x and 7 and the Smart Purge and Backup/Restore system, GroupWise can be configured to not automatically purge items that are deleted from the trash. Thus, before a backup has been done, nothing will truly be purged from the information store.

This is a powerful feature, but if your organization does not intend to use this, it's useless to have this feature enabled. In fact, with this feature enabled and used incorrectly, the information store will grow at an exponential rate. It's best to leave this option checked, until you are sure you've completely implemented the software for the Smart Purge and Backup/Restore system. Configuring and using these options is explained in Chapter 28.

CleanupPerform Maintenance Purges on Caching/Remote

This is a new feature to GroupWise 7. Prior to GroupWise 7, when a user downloaded mail in his or her Caching or Remote mailbox, the email was in a sense within the user's control, rather than within the GroupWise system's control. Now, with this feature enabled, and the GroupWise 7 client deployed, if an item is removed as a result of the Cleanup options, it is removed from the caching or remote mailbox also.

Threshold

The Threshold tab in the Environment Options box has to do with when users are connected directly to their post office via direct mode. Direct mode is a connectivity mode you can set on any post office. When a user is connected in direct mode, the threshold value determines the number of recipients of a message, within the post office the sender is on, who will have their user databases written to by the sender's GroupWise client.

Warning

Do not regularly allow your users to connect directly to their post office via direct mode; this opens you up for all kinds of corruption if used on a regular basis.


Client Send Options

Almost all the features under the Send option of the Client Options dialog box mirror 32-bit Windows client options. Most of the features should not be administered, unless you have some special business reason that requires you to administer or lock down a feature of the GroupWise client. Rather than explaining all of these GroupWise client-based features, this section discusses the client options under Send that are not available to the Windows client, or that are particularly noteworthy.

Allow Use of Reply to All in Rules

This option is unchecked by default. This is a good default that will cut down on vacation rules users might make that reply to all recipients of a message.

Allow Use of Internet Mail Tracking

Internet mail tracking is a feature that will work if your GWIA has Delivery Status Notification enabled. The Delivery Status Notification feature is discussed further in Chapter 10, "Installing and Configuring the GroupWise Internet Agent." If you have not enabled this feature on the GWIA, you might as well not tease users with a feature that will not work.

Wildcard Addressing

Wildcard addressing can allow users to send a message to a lot of other users. Fortunately, there is no dialog box in the GroupWise client that prompts or coaches users to use wildcard addressing. Generally this is a feature you will want to disable company-wide, and then enable for a few select people. For more information on how to use wildcard addressing, use the Help feature in the GroupWise client, and then read up on how to send a message with a wildcard address.

Wildcard addressing can be configured to enable users to send to the following:

  • Post office: All users on the sender's same post office.

  • Domain: All users on the post offices in the same domain as the sender's post office.

  • System: All users on all post offices in all internal GroupWise domains in the GroupWise system.

  • Unlimited: All users on all post offices in all internal GroupWise domains in the GroupWise system; all users on all external domains that you might have defined.

Allow Reply Rules to Loop

Starting with GroupWise 6.0x, there is some rule loop detection intelligence in the GroupWise POA that was designed to not allow reply rules to loop. Sometimes, though, the rule loop detection intelligence goes too far, and the result is that your users might complain that a rule fires off only once, and then never works beyond that. If you enable the Allow Reply Rules to Loop feature, your users should no longer experience this problem.

Global Signature

This feature is new to GroupWise 7. If a Global Signature has been created under GroupWise System Operations, the signature can be chosen from this drop-down dialog. A Global Signature isn't necessarily "global" because it can be enabled in the same granular manner as the other features available in Client Options.

Conceal Subject

This feature allows an administrator to indicate that the subject of messages should be concealed. This feature would generally be implemented on a limited basis, for special-purpose mailboxes.

Require Password to Complete Routed Item

When a user creates a message into a routing slip and recipients of the routing slip mark the slip as completed, the recipient will be prompted to enter the same password that was used to authenticate to GroupWise.

Secure Item Options

Using S/MIME is explained in detail in Chapter 30, "Creating a Secure Messaging Solution."

Disk Space Mgmt

With this feature, you can specify just how much disk space users' mailboxes can use, as well as the largest message that users can send.

Following are the settings you can set from the Disk Space Mgmt window:

  • Mailbox Size Limits: This is the maximum amount of space allocated to users for their messages and the attachments associated with those messages.

    Note

    Mailbox size is made up of anything in the user's mailbox, including items in shared folders and document references to documents in a GroupWise library.

  • Threshold for Warning Users: When a user is getting close to the quota of disk space, the GroupWise client warns the user that allocated disk space is getting low.

  • Maximum Send Message Size: Good when you don't want your users to send messages over a certain size. This option is one way to prevent users from using email as an FTP utility.

  • Perform Maintenance Purges on Caching/Remote: With this new feature in GroupWise 7, you can now enforce the same mailbox size limits on users' Caching and Remote mailboxes, wherever those mailboxes are located. The size limit is applied the next time the GroupWise Windows client synchronizes with users' Online mailboxes. Because users might lose items that they have been storing locally when the size limit is enforced, you should warn users that size limits are going to be placed on their local Caching and Remote mailboxes.


Understanding the Architecture Behind the Client Options Interface

As Chapter 3, "Understanding the GroupWise Directory," noted, the GroupWise administration snap-ins write changes directly to the GroupWise domain database to which the snap-ins are connected. For client options to take effect, however, the changes must propagate all the way down to the GroupWise user database, USER xxx.DB. Here is the flow of events:

  1. The administrator makes a change to client options.

    For example, imagine that you have unchecked the box labeled Allow Shared Folder Creation, and then locked that setting. Assume that the post office object was selected at the time you made the change. This means that the setting will apply to the entire post office.

  2. The GroupWise administrator snap-ins write the change to the GroupWise domain database and create an administration update file to propagate this change to the post office.

  3. The MTA transmits this file to the POA.

  4. The POA administration thread writes this change to the post office database.

  5. A POA writes (or merges) the change to the preferences capsule of the user database, or to the user databases that are affected by the changes in client options.

Note

The GroupWise client reads the preferences capsule of the user database when the client initially logs in. This means that if you make a client option change, the users will not normally see this change until they have logged out and back in with the GroupWise client.


Using Client Options to Lock Down the GroupWise Archive

The following scenario walks through the process of editing a client option. A company policy has been established that all GroupWise mailbox archives must be created on the network. All users have home directories mapped to the root of drive U:, and GroupWise administrators need to enforce the policy and force all archives for all users into their home directories. Here are the actions required to fulfill this scenario:

1.
From ConsoleOne, select a domain object.

If there are multiple domains in this system, perform steps 17 for each domain.

2.
Pull down the Tools menu and choose GroupWise Utilities, Client Options.

3.
Click the Environment button.

4.
Click the File Location tab to get to the screen shown in Figure 7.5.

Figure 7.5. File locationarchive path

5.
In the Archive Directory field, enter the following:

U:\archive

6.
Click the padlock button to lock this option.

Because you are doing this with a domain selected, the option will be locked for all users on this domain.

7.
Click OK and close out of the Environment Options dialog box.

At this point, all you need to do is wait for this option to propagate. The next time users log in, they will find that their archives must be created in their home directories.

Now, suppose users already had archives on the local drives. In this case, you have to move the archives manually, visiting each workstation. There is no central administration tool for working with existing GroupWise archives. If you want to administer an archive location, it is wise to decide this before users begin using the archive feature of GroupWise. Otherwise, they might lose access to the archives on their local drives.

Warning

If the user's archive path does not exist, the GroupWise client will not be able to run the auto-archive operation. In other words, using the preceding example, when the administrator defines the archive path to U:\archive and locks this down, the end user's client will not auto-archive the first time he or she logs in. This is because the user's unique archive directory does not exist under the U:\archive directory. The user will simply need to manually archive something, or go to File, Open Archive, and then close the archive. This will create the unique user directory with a couple of archive databases in the U:\archive\ofFIDarc directory. The next time the user logs into GroupWise from the GroupWise client, the auto-archive function will run. Remember that this applies only if you have enabled auto-archiving from the Cleanup tab. Any manual archives will work just fine, of course.


Expired Records

GroupWise administration allows you to set an expiration time on a GroupWise user's account. The Expired Records tool under Tools, GroupWise Utilities allows you to easily see accounts that have expired (see Figure 7.6).

Figure 7.6. The Expired Records window

[View full size image]

Note

Users who have expired can still receive mail, but they cannot open their mailboxes. Expiration is a useful way to deal with temporary or contract employees without having to commit to deleting their mailboxes.


Email Address Lookup

Many organizations want to make sure that their GroupWise user IDs are unique throughout the system. With this nifty feature (shown in Figure 7.7), you can type in your proposed Mailbox ID/User ID to see whether it has already been used. You can search for a user ID in the following manner:

  • User ID: ECORNISH

  • Portions of the user ID with a wildcard: EC*

  • The user ID at the user's Internet domain: ECORNISH@WWWIDGETS.COM

Figure 7.7. The Email Address Lookup window

Tip

The Email Address Lookup option will also find alias records. The search window must match exactly what a user has defined as an alias, however (for example, EVA-THE-EMAIL-QUEEN@WWWIDGETS.COM). This will be helpful to quickly search for an address you think might be coming from an alias record.

Also know that when you're creating a new user, the GroupWise snap-ins will automatically ensure that the user ID is unique within the GroupWise system. If this user ID already exists, you will receive an error stating that the email address conflicts with the address of an existing user (db57).


The Synchronize Tool

The synchronization process is not nearly as simple as the description you see when selecting Tools, GroupWise Utilities, Synchronize. Assuming that ConsoleOne is connected to the primary domain, and the administrator highlights a user and synchronizes the user who belongs to a secondary domain, this is what happens:

  1. eDirectory-specific information in the user object is rolled into the synchronization request.

  2. The synchronization request is sent to the secondary domain that owns this user.

  3. The secondary domain updates the user object with information that was extracted from eDirectory.

  4. The secondary domain bundles the GroupWise-specific information about the user object into another synchronization request.

  5. The secondary domain propagates the new information to its post offices.

  6. The secondary domain sends the request from step 4 to the primary domain.

  7. The primary domain propagates this information to all other secondary domains.

  8. All other secondary domains propagate the information to their post offices.

Note

Synchronize works on only the object you have highlighted. For example, if you highlight a post office, it sends a message to the entire system regarding the post office object itself. All the users on that post office are not synchronized, just the post office object itself.

The synchronization process initiated here is nearly identical to the process of updating or creating objectsthe only difference being that no "new" information is created. The record is simply being repropagated through the GroupWise directory.


User Move Status

The User Move Status utility allows you to track the progress of moved resources or distribution lists. This tool is tremendously helpful at resolving most problems related to moving a user. Chapter 13, "Moving Users," talks more about utilizing this utility.


Link Configuration

The Link Configuration tool allows you to define the connections and routes for messages on your GroupWise systemconnections and routes such as how a post office connects to its domain, or how one domain connects to another domain.

The Link Configuration tool is used to define the connections, or links, between the domains and post offices on your GroupWise system. These links govern the way that the GroupWise MTA routes messages.

Before exploring the Link Configuration interface, you need to be familiar with some terms:

  • Link type: Link types describe the type of route between two domains. A link type can be direct, indirect, gateway, or undefined:

    • Direct: A direct link between two domains means that those domains' MTAs "talk" directly to each other. There is no domain or gateway intervening.

    • Indirect: An indirect link between two domains means that a third domain is involved in any communication between them. For instance, if Domain A has an indirect link with Domain C through Domain B, the Domain A MTA will send to the Domain B MTA, and then it is up to Domain B's MTA to route the message to Domain C.

    • Gateway: A gateway link between two domains indicates that the domains must communicate through a gateway, such as Async or GWIA. In this case, both domains must have the same type of gateway installed at their systems. For instance, if Domain A has a gateway link to Domain B through the Async gateway, the Domain A MTA will hand the message to the Async gateway. This gateway will then dial Domain B's Async gateway to hand the message off again. Finally, Domain B's Async gateway will hand the message off to the Domain B MTA.

  • Link protocol: Link protocols describe the type of connection between two domains. Differentiating between link type and link protocol is easy. Think of a trip on a U.S. highway. Link type is like your routeyour choice of roads. Link protocol is like your choice of vehiclesit is your transport mechanism. The protocol choices offered are mapped, UNC, and TCP/IP:

    • Mapped: A mapped link is typically used by an MTA on an NT box. That machine must have a drive mapped to the link target. Mapped links to post offices require the MTA to actively poll the post office WPCSIN queues for mail to be transported. Mapped links take the form of drive letter:\path. The NetWare and the Linux MTAs do not support mapped links.

    • UNC: A UNC link is similar to a mapped link, in that an MTA with a UNC link to a post office must poll the post office WPCSIN queues. UNC links do not require drive mappings, however, and for that reason are preferred over mapped links. UNC links take the form of \\server\volume\path. The Linux MTA does not support UNC links; it only supports TCP/IP links.

    • TCP/IP: TCP/IP links are preferred over both UNC and mapped links. With TCP/IP, the MTA need not poll post office directories. The POA will poll the structure and will open a connection with the MTA only when there are items to be transferred.

No link type is better than another. For some organizations lots of indirect links will work well. For others, all domains will be linked directly. The size of your system will dictate your link types. UNC links should be eliminated, even in instances in which the two agents that must talk with one another are on the same server. The best link protocol is TCP/IP.

The Link Configuration window shown in Figure 7.8 has four main components:

  • The toolbar

  • The Domain drop-down menu

  • The Outbound Links pane

  • The Inbound Links pane

Figure 7.8. The Link Configuration utility

From this window, you can edit links and drag and drop links in order to change how agents link to one another.

If you have created your domains and post offices properly, assigning IP addresses and ports right away, you do not have to worry about the actual configuration of the agents. All you have to worry about is how the domain-to-domain links work. By default, newly created domains link to one another via the primary domain, and have an indirect link to all other domains. This isn't necessarily the best design for your system.

The Link Configuration Toolbar

The Link Configuration toolbar has eight action buttons on it. These buttons allow you to perform operations without accessing menu items. Here's a description of these buttons from left to right:

  • Open: The Open button allows you to connect to a different domain database for configuring links. You will be prompted for the path to a domain database.

  • Save: The Save button saves all changes you have made to link configuration in the current domain database.

  • Undo: If you have made changes but have not saved them yet, you can use the Undo button to revert to the original link configuration.

  • Help: The Help button opens the help file to the Link Configuration Contents page.

  • Find: The Find button allows you to find a domain link by entering a domain name. This is useful for very large systems.

  • Link: The Link button opens the highlighted link for viewing or editing. This is discussed further in Chapter 9, "Configuring the Message Transfer Agent."

  • Domain Links: The Domain Links button changes the display of the tool so that only domain links are displayed.

  • Post Office Links: The Post Office Links button changes the display of the tool so that only post office links are displayed.

You can accomplish each of the tasks shown on the buttons either through menu choices or by right-clicking and choosing from the menu.

The Domain Drop-Down Menu

In Figure 7.8, the Domain drop-down menu reads Corp (Primary). This means that the primary domain's links are being examined. Changing this to another domain does not change the system connection, however. Remember that all domains have copies of each other's recordsyou can be connected to one domain and change the links for a different domain.

To change the system connection, use the first button on the toolbar, or go to the File menu and select Open.

The Outbound Links Pane

The Outbound Links pane displays each of the outbound links, or "send" connections for this domain. Notice that domains displayed here are listed by link type, which is direct, indirect, gateway, or undefined. The View menu can also be used to display links to this domain's post offices instead of links to other domains.

The Inbound Links Pane

The Inbound Links pane displays each of the inbound links, or "receive" connections for this domain. The sales domain's outbound link to Corp will be the same as the Corp domain's inbound link from sales. Outbound links can be edited; inbound links are edited by changing the corresponding outbound link somewhere else.

Again, use the View menu to expand this display to include gateway and undefined links, or to switch to post office links.


Document Properties Maintenance

This menu option under Tools, GroupWise Utilities is available only when a post office is selected, and it allows you to customize default property sheets for documents in GroupWise libraries.

If document management fits into your GroupWise strategy, you will want to become familiar with this tool. With a post office object selected, the menu item is available under the GroupWise Utilities menu.

This tool allows you to do the following things:

  • Change the property sheet fields for documents for each GroupWise library

  • Create or edit lookup tables for populating certain property sheet fields

  • Add or edit document types to fit your document retention strategy

  • Create relationships between fields and between lookup tables

As already stated in Chapter 4, "Understanding the GroupWise Information Store," the GroupWise Document Management System is very complex. Enough so that document management really warrants its own book on the subject. If you are considering implementing GroupWise Document Management, you should consider obtaining the book Success with GroupWise Document Management, available at www.caledonia.net.


The New System Tool

If you have already created a GroupWise system, it is unlikely that you will want to use this tool. Most organizations fare better with a single GroupWise system spanning multiple domains than with multiple GroupWise systems.

When you launch ConsoleOne for the first time after installing the GroupWise snap-ins, the New System tool loads automatically. It walks you through the process of creating a GroupWise system, gathering domain and post office names, creating those objects, and then installing the necessary agent software.

This chapter does not discuss this interface, but you can find information about it in Chapter 2, "Creating a GroupWise System."


GW/eDirectory Association

This section discusses the options available when you select the GW/eDirectory Association option from the GroupWise Utilities menu.

Graft GroupWise Objects

The Graft Wizard helps you add GroupWise attributes to eDirectory user objects, and add GroupWise objects to the eDirectory tree. Recall that GroupWise has its own directory independent of eDirectory. The graft function is used on the occasions that a GroupWise object isn't in eDirectory, or is somehow not associated with its eDirectory object. Throughout this book, you can find instances in which you will be told to use the graft function. If you are creating a GroupWise system from scratch, you will not need to use this tool, because your eDirectory user objects will automatically be grafted to the GroupWise mailboxes you create.

Invalid Associations

The Invalid Association utility allows you to identify whether you have any invalid associations between your GroupWise directory store and eDirectory. Here are the steps you should take to use this utility:

1.
Highlight an eDirectory OU in ConsoleOne with users in it whom you are searching through in order to find invalid associations.

2.
Select Invalid Associations.

3.
The utility will look for objects in that eDirectory OU that have the following type of a problem:

  • eDirectory says that it has an object GBROWN.OU1.ACME that points to the GroupWise object GBROWN.PO1.DOMAIN1.

  • GroupWise reports that GBROWN.PO1.DOMAIN1 is associated with GBROWN.OU2.ACME.

The Invalid Association utility will then come up with a wizard that helps you resolve this potential issue. This issue could likely happen if you have regrafted objects, and somehow you grafted the users into an OU in which they did not originally exist, or your GroupWise system spans multiple eDirectory trees and there are user objects that GroupWise is pointing to in the wrong tree.

Disassociate GroupWise Attributes

The Disassociate GroupWise Attributes feature is the opposite of a graft. This feature is used when you want to disassociate a GroupWise object from its eDirectory object. This is often used for troubleshooting purposes. For example, you suspect that an eDirectory object has some corruption in it, and you want to delete the object from eDirectory but not from GroupWise. This is a perfect scenario to disassociate the eDirectory object from its GroupWise object.

As illustrated in Chapter 3, "Understanding the GroupWise Directory," and Chapter 5, "Working with GroupWise Objects," when GroupWise is first installed into a network, it adds attributes to, or extends, the eDirectory user object. This makes administration of user accounts much simpler.

Unfortunately, the synchronization between eDirectory and the GroupWise domain and post office databases is not perfect. Sometimes, particularly after a user moves, the eDirectory user object contains inaccurate GroupWise attributes, and the user mailbox can no longer be administered from ConsoleOne.

Here is where the Disassociate GroupWise Attributes tool comes into the game. This tool strips all the GroupWise information from the highlighted user's eDirectory object.

The Disassociate GroupWise Attributes tool has no interface window of its own. To remove GroupWise attributes from a user, do the following:

1. | Select the user object in either the eDirectory or the GroupWise view.
2. | Pull down the Tools menu and choose GroupWise Utilities, GW/eDirectory Association, Disassociate GroupWise Attributes.

If you were to use Display Object tool under Tools, GroupWise Diagnostics, on a user whose GroupWise attributes had been removed, you would find that none of the attributes with NGW in their names (the GroupWise schema extensions) was populated. Also, "GDS" (GroupWise directory services) information would appear. The eDirectory object would no longer be linked to a GroupWise object.

When GroupWise attributes have been removed, the user's mailbox still exists. All that has happened, in practical terms, is that the link between the GDS and eDirectory systems has been broken for this user.

Convert External Entity to User

The Convert External Entity to User tool allows you to take a GroupWise external entity user who does not currently have an eDirectory account and convert that user to a GroupWise user with an eDirectory account. By converting an external entity into a full eDirectory user, the user can leverage services from eDirectoryfor example, LDAP authentication or password expiration.

Tip

You can select multiple external entities in eDirectory and convert them all to full eDirectory users in one step.

Convert User to External Entity

The Convert User to External Entity feature allows you to take a GroupWise user who also has an eDirectory account and convert that user and eDirectory account so that it's an external entity. External entities have a green shirt (rather than a red shirt on a typical eDirectory user object), and external entities have no eDirectory rights. External entities do not use an eDirectory license, which is typically the motivation behind making a user an external entity. So if you are sure that this user does not need eDirectory rights or services, go ahead and make the user an external entity.

Tip

You can select multiple eDirectory user objects and convert them all to external entities in one step as well.

Note

If you are using LDAP authentication, external entity users cannot authenticate to eDirectory via LDAP. That being the case, you must assign a GroupWise password to external entities to allow them to get into GroupWise.


GroupWise Diagnostics

This section discusses the options available when you select the GroupWise Diagnostics option under the GroupWise Utilities menu. You probably won't use GroupWise Diagnostics often, but the feature sure is handy when you are doing hard-core troubleshooting.

Display Object

One of the most useful tools the developers have for debugging is the Display Object tool shown in Figure 7.9. This window bypasses the usual object details windows and displays all record data as straight text.

Figure 7.9. Displaying an object in GroupWise Diagnostics

[View full size image]

This is a useful tool for viewing all the information about any object in your GroupWise system in one simple view. GroupWise Diagnostics is particularly helpful because it allows you to see some information that is not available any other place. GroupWise Diagnostics is an information-gathering tool, but it in no way does a health-check type diagnosis of a GroupWise system or object. At various points throughout this book, you'll be told to use GroupWise Diagnostics to garner some little piece of information.

In the example in Figure 7.9, a user named Glenn Brown has been highlighted when the Display Object menu was selected. The top pane shows the GDS (GroupWise Directory Store) information. The bottom pane establishes the context and class of this object record in eDirectory. Then you are given a flat list of attribute names and values.

Record Enumerations

The Record Enumerations tool is similar to the Display Object tool, but it shows only information from the GDS system, as read from the connected GroupWise domain database. Also, the Record Enumerations tool references objects via several record type indexes available as a drop-down list.

Unlike Display Object, the Record Enumerations tool shows the same information regardless of what was selected when the tool was activated. Record Enumerations is a window into the "guts" of the domain database, and from the Record Enumerations window, shown in Figure 7.10, any record can be selected.

Figure 7.10. The Record Enumerations window in GroupWise diagnostics

[View full size image]

Like the Display Object tool, Record Enumerations is typically useful when troubleshooting synchronization problems.

Information

The Information tool, shown in Figure 7.11, is available when almost any object in the GroupWise system is highlighted. The Information tool is a good way to get a bird's-eye view of a system, domain, or post office.

Figure 7.11. The Information dialog box

Previous Page
Next Page


Summary

This chapter covered the GroupWise Utilities and GroupWise Diagnostics menus. During the rest of this book, you will weave in and out of many of these tools, using them for maintenance, troubleshooting, and all kinds of configuration.


Part III: Agents and Clients

8 Configuring the Post Office Agent

9 Configuring the Message Transfer Agent

10 Installing and Configuring the GroupWise Internet Agent

11 Installing and Configuring GroupWise WebAccess

12 Administering the GroupWise Client


Chapter 8. Configuring the Post Office Agent

The Post Office Agent (POA) is the workhorse of the GroupWise system. It is responsible for delivering mail to users, providing them with access to their mailboxes in client/server mode, indexing mailboxes and libraries, maintaining and repairing the message store, and redirecting users to other post offices for proxy or login.

It can be complicated to correctly configure the POA. After all, there is a lot for it to keep track of, and if your POA cannot accomplish everything with the CPU cycles the server gives it, your users will notice. This chapter explores many of the settings and console commands for the POA, and offers you some best practices to help you design and configure your system correctly.


Loading the POA

The GroupWise POA requires certain information before it will load properly. Simply typing LOAD GWPOA.NLM from a NetWare server console, for example, will result in an error message stating that the required parameters are missing. There are two ways to provide the required parameters, as described next.

Using the Startup File

When the GroupWise agent installation program ran on your server, you were prompted for some information. The install wizard, in order to create a startup file with all the information the POA needs, used this information. The name of this file is the name of the post office, truncated to eight characters, followed by the .POA extension (for example, CORPPO1.POA). To use the startup file, load the POA with the @ switch as shown here:

NetWare:

LOAD GWPOA @filename.POA

Thus, for the CORPPO1 post office, the command is as follows:

LOAD GWPOA @CORPPO1.POA

Linux:

/opt/novell/groupwise/agents/bin/gwpoa @../share/filename.poa

Thus, for the CORPPO1 post office, the command is as follows:

/opt/novell/groupwise/agents/bin/gwpoa @../share/corppo1.poa

Tip

On NetWare the command assumes that the GroupWise POA software is installed into the SYS:SYSTEM directory on a NetWare server, and the CORPPO1.POA file is also in the SYS:SYSTEM directory. The name of the *.POA file is not particularly importantit could be called MICKEY.POA or MICKEY.TXTthe POA doesn't care.

Using Command-Line Switches

Another way to provide the POA with the information it needs is to use command-line switches. These switches take the general format of / parameter=value. On the Linux platform the leading slash (/) is replaced by a dash (-). Neither the parameter nor the value strings are case-sensitive for the NetWare or Windows POA. On the Linux platform, switches and value strings are case-sensitive. A rule of thumb for the Linux POA is to keep all switches and parameters lowercase. The only exception is the -home switch for the Linux POA. If the path to the post office's home does have any uppercase characters, this should be reflected in the home switch.

Any number of switches can be placed on the command line used to load the POA, and they can even be used in conjunction with the @ switch described in the preceding section.

The only required switch for the POA is the home switch, which gives the agent the path to the post office to be served. The syntax is as follows at a NetWare server:

LOAD GWPOA /HOME-volume:\path

For a post office residing in the PO directory on the MAIL volume of a NetWare server, the command line would look like this:

LOAD GWPOA /HOME=mail:\po

For a post office on a Linux server, the syntax would look something like this:

/opt/novell/groupwise/agents/bin/gwpoa home=/mail/po

Learning the Switches

Almost all the switches the POA will recognize are listed in the startup file that gets installed when the GroupWise agents are installed. By now you've probably figured out that the startup file is just a shortcut for passing command-line switches to the POA. Any switch found in this file can be entered on the command line used to load the agent.

Tip

You can discover most of the switches for the GroupWise NLM POA by loading the GroupWise POA with the /? switch, as in the following example:

LOAD GWPOA /?

You can discover most of the switches for the GroupWise Linux POA by loading the GroupWise POA with the help switch, as in the following example:

/opt/novell/groupwise/agents/bin/gwpoa help

When to Use Switches

When loading a GroupWise POA, you usually do so with a command line such as this:

NetWare:

LOAD GWPOA @CORPPO.POA

Linux:

/opt/novell/groupwise/agents/bin/gwpoa @../share/corppo.poa

The CORPPO.POA file is just an ASCII file that contains a listing of all the documented GroupWise POA switches that can possibly be enabled. Ideally, the only switch that should be enabled is the home switch:

NetWare:

/home=vol1:\CORPPO

Linux:

-home=/mail/corppo

Most of the switches map to a location in ConsoleOne where the functionality that the switch is mapping to in the GroupWise POA code is configurable from ConsoleOne. For those switches, use ConsoleOne. For example, rather than having the /httpport=8300 switch enabled in the startup file of the POA, you edit the POA in ConsoleOne and configure the HTTP port field on the Network Address property page of the POA. By managing the features that are mapped to settings in ConsoleOne, it's much easier to make changes to the POA. Most of these changes can happen on the fly when you make changes from ConsoleOne. With the GroupWise POA, however, when you make a change to the startup file (CORPPO.POA, in this example), you must manually bring down the POA and restart it.

Tip

Although the Linux POA requires a dash (-) for switches passed on the command line, switches in a startup file use the forward slash (/). The reason Linux requires dashes is that the forward slash character is reserved by Linux to reflect file paths.


Configuring the POA

The numerous startup switches are probably a poor choice of tools for configuring the POA. You must have file-system access to the location where the startup files are in order to apply them, and the values they represent will be visible only to those with access to the location where the files are located.

The solution is to administer the POA through ConsoleOne. Each post office object has a child object representing its POA. Double-clicking this object from the GroupWise view (or selecting Properties from the right-click menu) opens the window shown in Figure 8.1.

Figure 8.1. The POA property page in ConsoleOne

[View full size image]

The rest of this section examines each of the eight property pages on the GroupWise tab of the POA: Identification, Agent Settings, Network Address, QuickFinder, Maintenance, Log Settings, Scheduled Events, and SSL Settings.

The Identification Property Page

The information on the Identification property page is not critical to the tuning of the POA, but it does help identify the POA as a unique object within the system. This page is the one that is visible when the POA object is first opened, and it is shown in Figure 8.1. The objects shown include the following:

  • Description: The string entered in this field is visible at the top of the POA screen on the server console.

  • Platform: The drop-down list here offers four choices:

    • NetWare Loadable Module: Use this if you have GWPOA.NLM running on a NetWare file server.

    • Windows: Use this if you are running GWPOA.EXE on a Windows NT, Windows 2000, or Windows XP box.

    • Linux: Use this if you are running gwpoa on a Linux server.

    • Other: There is probably no need for you to use this entry. It is here for possible future compatibility.

You really cannot configure this page wrong. We recommend that you fill in the description field with something useful that will display on the POA's console screen.

The Agent Settings Property Page

The Agent Settings property page is where you find most of the POA settings that directly affect the POA's performance, and thus the end-user performance, in the end user's GroupWise client. The following list explains these settings:

  • Message File Processing: There are four available settings here. They roughly correspond to the WPCSOUT queues, and determine which priorities of messages this POA will process.

    • All: Under this default setting, the POA will poll all WPCSOUT queues for message files.

    • Low: The POA will process messages in only the 4, 5, 6, and 7 (normal and low-priority) queues.

    • High: The POA will process messages in only the 0, 1, 2, and 3 (high-priority) queues.

    • Off: The POA will not perform any message-file processing.

In most customer environments, the POA should be set to process all. In the case of a dedicated QuickFinder indexing POA, though, you might want to change this to Off.

  • Message Handler Threads: This setting determines the number of threads the POA will devote to the message file processing. This should not be more than half the number of TCP handler threads (see the next bullet). Generally, one message handler thread for every 50 users on the post office is sufficient. The lowest number of message handler threads you should allocate is three.

  • Enable TCP/IP (for Client/Server): When checked, this option allows the POA to listen and respond to client/server requests. This is required for the client/server access mode.

Tip

If you disable TCP/IP (for client/server) on the POA, you must shut down the POA and restart it for this setting to take effect. This is because the POA must stop listening for client/server requests on its client/server port, and to do this, it must be shut down and restarted. The same rule applies if you have it disabled and then enable it.

  • TCP Handler Threads: This setting determines the number of threads the POA will devote to handling client/server requests. Increasing this number might improve client/server performance, but only to a point. As a rule of thumb, you should have one TCP handler thread for every 25 users on the post office. The lowest number of TCP handler threads you should allocate is six. Setting the TCP handler threads beyond about one thread per user will not necessarily improve the performance of the POA. In fact, the POA might take up more CPU cycles than is currently needed if this is set too high. From moment to moment, the POA uses fewer TCP handler threads to support users who are using the GroupWise client in caching mode. However, use the same rule of thumb for threads to users as explained earlier.

Tip

If you have allocated too few TCP handler threads, the POA will dynamically allocate more if needed. You can configure a maximum of 99 TCP handler threads.

  • Max Physical Connections: This sets the maximum number of physical connections, or ports, that the POA will allow to be open simultaneously. If this number is reached, and a new user attempts to log on, that user will receive an error message and will not be able to connect. Set this to be equal to or slightly higher than the total number of users on this post office. Be sure to take into account users running GroupWise from more than one machine, or users who are proxied to or from other post offices.

  • Max App Connections: This sets the maximum number of application, or virtual, connections that the POA will allow to be open at any given time. If this number is reached and a client attempts to open another application connection, the oldest connection in the table will be dropped. The client whose connection has been dropped might attempt to reopen it, however, so reaching this threshold can cause a serious performance hit as dropped connections cascade through the clients. One GroupWise client has the capability to use a few application connections. Set this to be equal to about four application connections per user associated with the post office.

  • Enable Caching: When this option is checked, the POA will store the last several database files it has "touched" in memory for quick access. This is in addition to any caching done by the operating system, and it typically improves agent performance.

Note

This setting is not be confused with the "caching" mode of the GroupWise client. If you are looking to control whether users can switch their GroupWise client to caching mode, edit the Client options of the Post Office object. Select Environment, Client Access and make changes to the caching mode settings.

Tip

If you disable caching of databases on the POA, the POA does not dynamically "uncache" the databases that it currently has cached in memory. The POA must be shut down and restarted.

  • CPU Utilization: This value is a trigger based on server utilization, and it is used in conjunction with delay time (discussed next). Should utilization climb above this number, the POA waits for the specified delay time before spawning a new thread. This throttles back the POA, perhaps preventing server utilization from sticking at 100% for extended periods. This setting applies to the POA only when it is running on the NetWare platform.

  • Delay Time: Used with CPU utilization, this is the amount of time, in milliseconds, that the POA waits before spawning a new thread. This setting applies to the POA only when it is running on the NetWare platform.

  • Max Thread Usage for Priming and Moves: This is an interesting setting that you might want to move beyond the default of 20%. For example, if you were moving many users off of a post office, you could tweak this setting to 50% during the user moves. Or if you had a post office that was largely dedicated to users in caching mode, you should also consider changing this setting to 50% during the original time that users are establishing their caching mailboxes.

  • Enable IMAP: If this option is checked, the POA will allow users to access the GroupWise POA via an IMAP client. The IMAP protocol has a rich feature set, so it is quite feasible to allow IMAP clients, such as Microsoft Outlook Express, to access the GroupWise system via IMAP.

Note

The IMAP protocol defines the method for handling the display and deletion of messages in an IMAP user's mailbox. The IMAP protocol does not support sending messages. Any IMAP client that must send messages must do so using an SMTP relay server. So if you enable IMAP at the POA, make sure that you have configured a GroupWise Internet Agent (GWIA) in your GroupWise system to allow message relaying, or have the IMAP client authenticate to the GWIA in order to send mail. It is generally best not to allow message relaying on a GWIA that is accessible to the Internet. Chapter 10, "Installing and Configuring the GroupWise Internet Agent," talks more about configuring the Allow Message Relaying option on the GWIA.

  • Max IMAP Threads: This sets number of IMAP clients that can be requesting an IMAP session with the POA at one time. If a user's IMAP session is inactive for a few minutes, the IMAP session times out. Set this to one IMAP thread per potential IMAP client that will access the post office.

  • Enable SOAP: If this option is checked, the POA will allow users to access the GroupWise POA via a SOAP (Simple Object Access Protocol) compliant client. This is an important interface for Evolution, which is one of the most popular mail clients on the Linux platform, and is included in most Linux distributions, because it will use the SOAP interface to connect to GroupWise. Also some of the third-party server-based PDA synchronization solutions are expected to use this interface in the near future. This feature might also have to be enabled in conjunction with a development environment.

  • Default SOAP Threads: This sets number of SOAP clients that can be requesting a SOAP session with the POA at one time. Be judicious as to how many SOAP threads you dedicate because they can take considerable overhead.

  • Max SOAP Threads: This sets number of SOAP clients/threads that can be requesting a SOAP session with the POA at one time.

  • Enable SNMP: If this option is checked, the POA will "publish" SNMP information for any management agents that are listening.

  • SNMP Community "Get" String: The fields for SNMP community strings are not required unless you are using a third-party Simple Network Management Protocol (SNMP) product.

  • HTTP Username/Password: This is the password you intend to use when monitoring your POA through a Web browser. There are monitoring features of the POA that you cannot get from the POA's console screen, but you can get from the HTTP monitoring screen of the POA. So it is a good practice to define the HTTP username and password. The username and password do not need to correlate to an eDirectory user. This feature of monitoring the POA with a browser is discussed toward the end of this chapter, in the section "Monitoring Your POA Through a Web Browser."

Outside of server performance, the settings on the Agent Settings page have the most significant impact on the performance of the POA. Be sure to tune your POA according to the recommendations in this section.

The Network Address Property Page

The fields in the Network Address window, shown in Figure 8.2, are needed for the GroupWise POA to listen for client/server connections from a GroupWise client, and for the POA to listen for messages from the MTA servicing the domain above the post office the POA is running for. The SSL portions of this screen are not discussed in this chapter. Chapter 27, "Securing Your GroupWise System via SSL," gives detailed information on how to enable SSL on the POA.

Figure 8.2. The POA Network Address property page in ConsoleOne

[View full size image]

The fields that appear are listed here:

  • TCP/IP Address: This field should display the TCP/IP address or DNS address for the server where the POA is running.

Note

If your server happens to have two or more IP addresses bound to it, using this field to define the TCP/IP address you want the POA to listen on is not sufficient. You must add the following switch into the startup file of the POA:

/IP-IP address bound to the server that you want the POA to listen on

For example:

/ip-137.65.55.211

Tip

If the POA needs to be moved to another server, or the server's IP address must be changed, be sure to change the IP address for this POA to match the IP address of the server.

  • Proxy Server Address: This setting is relevant if you intend for your users to use caching or remote modes, and you want to enable access to the post office when these users are connected to your system via an Internet connection. The proxy IP address must be a public class IP address, and this address will actually map (or be bound) to an IP address on a proxy server or L4 switch (Layer 4 network switch).

Note

Your proxy server or L4 switch should be configured to use NAT (network address translation) in order to send traffic to the proxy server address back to the TCP/IP address defined (or bound) on the POA. The GroupWise client will speak to the proxy server or L4 switchat the same client/server port that the POA is configured to listen to for "normal" client/server sessions. This is typically port 1677.

  • IPX/SPX Address: This setting is relevant only if you use SNMP software that can access an IPX address.

  • Message Transfer: The Message Transfer field identifies the port that will be used for communication from the domain MTA for the domain that owns this post office, down to the POA process that is running for this post office. If this field is not populated, the MTA will require direct file access to the post office directory structure. If there is a port number here, however, the MTA can transfer files to the POA using a TCP connection.

    The default value for a message transfer port is 7101. If there are multiple post offices on this server, each of them must be assigned a unique message transfer port. You might use sequential numbering in cases like this (for example, 7101, 7102, and so on). Also, if there is an MTA running on the same server as the POA, the MTA by default will listen on port 7100. You would need to use a port other than the default 7100 for the POA when the MTA is running on the same server as the POA.

  • HTTP: The HTTP port is used by the POA and the GroupWise monitor utility. This port tells the POA which port to listen to when monitoring Web browsers. This GroupWise Monitor utility reads the HTTP port value from the domain database, in order to monitor the POA.

Tip

If you enable HTTP monitoring, you will also want to enable the HTTP username and the HTTP password. To do this, go to the Agent Settings property page and fill in the HTTP Username and HTTP Password fields. If you don't define the HTTP username and password, anyone can access the POA's HTTP port without being prompted for authentication. Not a good thing to have wide open.

  • Local Intranet Client/Server: Enter the client/server port for this POA at the bottom of this window. If you are unsure of this value, use the default port, 1677. If there are multiple post offices on a single server, each of the POAs will need a unique port. You might use sequential numbering in this case (for example, 1677, 1678, 1679, and so on).

Note

To fully configure the POA for client/server connections, make sure that the Enable TCP/IP (for client/server) check box is checked on the Agent Settings property page.

  • Internet Proxy Client/Server: This field is relevant to the Proxy Server Address field mentioned earlier. This allows administrators to use the same proxy server address for all the POA agents in the GroupWise system, and then simply define different Internet client/server ports per POA. As discussed earlier, the proxy server would NAT the proxy IP address and Internet client/server port to the appropriate POA's IP address and client/server port on the company's backbone.

  • IMAP: If you intend to enable IMAP connectivity to the POA, it is advisable to keep the IMAP port at 143, because this is the default port for the IMAP protocol.

  • SOAP: If you intend to enable SOAP connectivity to the POA choose a port. The factory default is 7191.

Note

To fully configure the POA for IMAP or SOAP connections, make sure that the Enable IMAP or SOAP check boxes are checked on the Agent Settings property page.

You might have also noticed that each port has the option to enable SSL. This option is discussed in Chapter 27.

The QuickFinder Property Page

The GroupWise message store can be fully indexed. Indexing is an essential part of the Find feature in the GroupWise client. You will want to make sure that QuickFinder Indexing is enabled. If it is not, the GroupWise POA will have to do real-time indexing when the user uses the Find feature. When the POA is required to do real-time indexing, the POA's performance is degraded.

Following is an explanation of the settings on the QuickFinder property page, and some recommendations regarding these settings:

  • Enable QuickFinder Indexing: If this option is enabled, the QuickFinder indexing process launches at the interval specified under the QuickFinder Interval setting. The first launch takes place as scheduled under Start QuickFinder Indexing.

  • Start QuickFinder Indexing: Because the QuickFinder process is CPU-intensive, it might be useful to schedule it to occur only outside of business hours. The number you set in this field is in the form of hours after midnight. For example, if you set Start QuickFinder Indexing to 4, and set QuickFinder Interval to 12, the first indexing run will execute at 4 a.m., and the second will execute at 4 p.m. The second run will be more intensive than the first, catching all of that day's mail. The next 4 a.m. run will pick up any messages that were created in the late evening or early morning.

  • QuickFinder Interval: This is the number of hours and minutes the POA will delay between spawning the QuickFinder index update process. This setting is best used in conjunction with Start QuickFinder Indexing, discussed in the previous bullet. Generally, the default of 24 hours is the best setting. By setting the QuickFinder interval for every 24 hours, and coupling the Start QuickFinder Indexing setting to happen in the nighttime or early morning hours, you can keep the CPU-Intensive QuickFinder indexing process from kicking in during business hours.

    It is essential that you do not turn off QuickFinder indexing completely. It is best to run it once a day, during off-peak hours.

Tip

The GroupWise POA indexes only around 500 items in a QuickFinder pass, even if the user has more items to index. Generally, if QuickFinder runs every night, this default is sufficient. However, if a user's database is rebuilt, or if the user has moved to a new post office, the user's entire mailbox must be reindexed. If your QuickFinder indexing isn't taking too long to run at night, it might be best to add the undocumented switch /QFLEVEL=3 in the startup file of the POA. This tells the POA to process 2,000 items to be indexed before moving to the next user, if there are that many items that must be indexed.

The Maintenance Property Page

From the Maintenance property page of the POA, shown in Figure 8.3, you can define some of the daily routines that the GroupWise POA should run.

Figure 8.3. The POA Maintenance property page

[View full size image]

It is best to design these routines to execute during off-peak hours. Settings include the following:

  • Enable Automatic Database Recovery: When checked, this setting allows the POA to rebuild damaged databases it encounters while processing messages or client/server requests. It is highly recommended to leave this setting enabled. If it is disabled, you are setting yourself up for potentially serious database corruption issues and performance problems.

  • Maintenance Handler Threads: These are the threads that can be spawned when the POA must run a Mailbox/Library Maintenance (GWCHECK) job on the message store. The default is 4; if you generally keep your Mailbox/Library Maintenance jobs running after business hours, you can set this to the maximum of 8.

  • Perform User Upkeep: If this option is enabled, it allows the POA to do the following:

    • Advance uncompleted tasks to the next day

    • Delete expired items from users' mailboxes

    • Delete Mail, appointments, tasks, and notes that are older than what's defined in client options when client options have been set to automatically delete these types of items

    • Empty the trash based on client options

    • Synchronize users' frequent contacts books with the system address book

    • Clean address book indexes

    • Expire references from the document folder

Note

When the POA actually executes the Perform User Upkeep code, the upkeep happens in two passes. In the first pass the POA advances uncompleted tasks and synchronizes users' frequent contacts books with the system address book. In the second pass, the POA deletes expired items from users' mailboxes, cleans address book indexes, and expires invalid references from the document folder (if you are using GroupWise Document Management).

  • Generate Address Book for Remote: If this option is enabled, it allows the POA to generate a WPROF50.DB file for GroupWise caching and remote users. This file is the system address book for caching and remote users. This setting is used with the Start Address Book Generation setting.

    Note

    The WPROF50.DB file is found in the post office path\WPCSOUT\OFS directory.

    Tip

    When caching or remote users download the remote address book, it is placed on the remote machine with a filename WPROF.DB instead of WPROF50.DB, as it appears in the post office directory.

  • Start Address Book Generation: Denoting the number of hours after midnight, a value of 2 results in a 2 a.m. run, whereas a value of 22 results in a 10 p.m. run.

Tip

Address book generation usually takes less than five minutes to complete; it is a very quick process.

  • Disk Check Interval: This sets the amount of time, in minutes, that the POA will wait before rechecking the amount of disk space available. The disk check interval is directly tied to any disk check scheduled event configured for this POA. (Scheduled events are discussed in more detail in Chapter 17, "Maintaining the GroupWise System.") These events have thresholds of remaining disk space, and if the POA disk check determines that the GroupWise volume has dropped below that threshold, it spawns that disk check event's actions.

  • Disk Check Delay: Should a disk check event be triggered by a disk check, it might take some time for that event to free up some space. The disk check delay is the amount of time the POA will wait, regardless of thresholds that have been tripped, before spawning another disk check event.

You should keep all the settings on this page enabled. The only thing that needs fine-tuning is when you perform these tasks. The maintenance settings should be configured to happen during nonpeak hours. The Perform User Upkeep function should happen sometime after midnight.

The Log Settings Property Page

The Log Settings property page allows you to control the amount of information captured in the POA log, as well as the amount of disk space that old logs will take up.

Here is an explanation of the settings on this page, along with a couple of recommendations:

  • Log File Path: By default, this field is blank. POA logs are placed in the WPCSOUT\OFS directory under the post office directory. If you choose to keep logs elsewhere, enter the path here. We don't recommend that you put logs on a separate serverperformance might suffer, and if that server goes down, the POA will not function.

  • Logging Level: There are three menu items in this list:

    • Off: No logging.

    • Normal: The POA tracks "major" events in the log, but most of the detail will be gone.

    • Verbose: The log contains useful detail and is the recommended setting.

  • Max Log File Age: This sets the oldest that any log file on disk can be before the POA deletes it. The default is seven days, and this is typically sufficient.

  • Max Log Disk Space: This sets the maximum amount of disk space that all the log files together can consume. If the logs reach this limit, the oldest log file is deleted. The Max Log Disk Space setting overrides the Max Log File Age setting in that if the Max Log Disk Space threshold is met, it doesn't matter how young a log file is, it's going to be deleted. If you choose to set the Max Log File Age beyond seven days, you will want to raise this limit to make sure that you actually keep your oldest logs for the time that you specify. Unfortunately, this can be very difficult to estimate. The POA will generate a new log file when the old one reaches 1025KB (1MB) in size.

POA logs are an important troubleshooting tool. We recommend configuring the POA so that you can take the best advantage of this tool.

The Scheduled Events Property Page

You will use the Scheduled Events tab to automate message store maintenance. You can use this page to configure the POA to run mailbox/library maintenance (GWCHECK) on a post office at some kind of a time interval. One of the best things about scheduled events is that they can be configured to happen when the system is being used the least. Chapter 17 discusses scheduled events in more detail.

The SSL Settings Property Page

From the SSL Settings page you configure your POA to use SSL. Chapter 27 tells how to utilize SSL on the POA. The capability to use SSL to encrypt communication is overhead for many customers, but it helps the security folks sleep better at night!


Monitoring and Configuring the POA at the Console Screen

The NetWare POA has a user interface and thus can be monitored from the NetWare server's system console. By default, both the Linux and the Windows POAs are designed not to load with a user interface. Primarily this is done to save CPU cycles so that the server does not need to maintain the refreshes and so on of a graphical user interface. If, however, you would like to see the user interface of the GroupWise POA, you may. To do so on the Windows platform, just do not load the POA as a Windows service. To do so on the Linux platform, load the GroupWise POA with a -show switch passed from a command line. For example:

/opt/novell/groupwise/agents/bin/gwpoa show @../share/po1.poa

This section talks of the GroupWise POA user interface from the perspective of a NetWare POA. The same features are roughly available in both the Linux and the Windows POA, but only if these POAs are loaded with a user interface.

Like many Linux programs, the script that loads the Linux POA supports the following command-line switches, after it has been loaded:

/etc/rc.d/grpwise start
/etc/rc.d/grpwise stop
/etc/rc.d/grpwise restart
/etc/rc.d/grpwise status

After the GroupWise POA on NetWare has successfully loaded, the screen shown in Figure 8.4 will be available from the server console or from a remote console session.

Figure 8.4. The POA console on a NetWare 6.5 server

[View full size image]

Tip

Remember, to load the POA on NetWare, type LOAD GWPOA @STARTUPFILENAME.POA. (By default, the startup filename is the name of the post office.)

You can control the NetWare POA, to some extent, with keyboard commands you issue. The commands available from the main screen are the following:

  • F4: Configuration

  • F7: Exit

  • F9: View Log File

  • F10: Options

The F7 and F9 keystrokes need little explanation. Pressing the F7 key unloads the POA. If client/server connections are active, or if the QuickFinder indexing process is running, you will be prompted to confirm your decision to exit. Pressing the F9 key allows you to browse through the currently active log file.

The Configuration Options Menu

When you press the F4 key, the menu shown in Figure 8.5 appears.

Figure 8.5. The POA Configuration Options menu

Each of the menu items here pumps information into the active log file when executed:

  • Show Configuration: This option lists the configuration values and settings currently in memory. The settings you learned about in the section "Configuring the POA" are listed here. This list is identical in nature to the list of settings that the POA displays when it is first loaded. This list is not displayed in its own static window; rather it is dumped into the current active log of the POA. To review the configuration, press F9 to view the log file.

  • All C/S Statistics: As the name suggests, this option dumps a list of all the client/server statistics into the current log file. Each of the options that follow in the rest of this bulleted list is a subset of this option, and those individual statistics are covered in their respective sections.

  • General C/S Statistics: This option creates a section in the log file titled TCP Configuration. Beneath this section, you will find values for the configured limits of application and physical connections (Max), as well as the current number of active connections (Cur) and the highest the current value has reached (High).

  • Physical Connections: This option lists the IP address and GroupWise user ID for each user who has a physical connection to the POA. A physical connection is a memory address for the transmission and receipt of TCP packets and will correspond to a port number. The port number used by the client and the POA for each connection is unfortunately not displayed. The numbers range from 1024 to 2048 or higher, depending on the number of users currently logged in.

  • Application Connections: This lists the IP address and GroupWise user ID for each user who has an application connection to the POA. Most users will have more than one application connection, because these connections represent the windows or applications within the GroupWise client that are sharing the user's current physical connection. For example, a user with only the Inbox window open can have only one or two application connections. A user reading a mail message, running Notify, and browsing a shared folder will have at least three, and perhaps as many as six, application connections.

  • View Throughput: This displays the client/server TCP/IP throughput for the POA. It does not include message transfer throughput or files processed from the WPCSOUT queues.

  • Clear Throughput: Use this option to clear the throughput count. When view throughput is executed, the throughput calculations will be based on the last time the throughput was cleared, or the last time the agent was loaded.

  • Show Redirection Tables: This option shows each of the POAs on the system, and their configured IP addresses and ports. The redirection table is used by the POA to connect users to other post offices for proxy purposes, for connections to libraries, or for redirected logins. The list shown here is from the perspective of this post office. Discrepancies between addresses shown on this list and addresses configured from ConsoleOne indicate a synchronization problem.

  • Check Redirection Links: This option is the same as the Show Redirection Tables option, except that after each entry is listed, the POA attempts to connect to the POA at that address and shows the results of that attempt.

    This tool is especially valuablewith one keystroke, you can determine which POAs on your system are responding and which are not.

You will use these options and statistics on rare occasions, generally when troubleshooting communication problems.

The Options Menu

Pressing the F10 key pulls up the menu shown in Figure 8.6.

Figure 8.6. The POA Options menu

When troubleshooting the POA, you will use the Options menu rather often. Settings include the following:

  • View Log Files: This option is similar to the main screen's F9 keystroke, but it offers more options. It brings up a list from which you can choose to browse not only the current log file (marked with an asterisk) but also any of the POA logs that reside on-disk.

  • Logging Options: This option brings up the screen shown in Figure 8.7.

    Figure 8.7. The POA Logging Options menu

    Use the up- and down-arrow keys to navigate and the Enter key to edit the selected logging option. The Esc key takes you back to the main screen.

Tip

It is better to configure the POA logging from ConsoleOne. This way, the POA always starts with the settings you have selected. Reserve making changes from the POA's console screen for temporary situations and when troubleshooting. When you make changes from the POA's console screen, those changes aren't retained after the POA has been unloaded and reloaded. The option for diagnostic logging is not available from ConsoleOne. Generally you do not want your POA to perform diagnostic logging except for short periods of time. If by chance, though, you do want your POA to start with diagnostic logging, just add the /debug startup switch to the startup file of the POA.

  • Configuration Options: This menu option is identical to the main screen's F4 keystroke.

  • Admin Status: Selectin g this option brings up the submenu shown in Figure 8.8.

    Figure 8.8. The POA Admin Status screen

There are four available actions or configuration options in this dialog box. Again, use the up- and down-arrow keys to navigate, and press Enter to edit. These two options are especially useful:

  • Perform DB Recovery: This executes an immediate recovery of WPHOST.DB. A recover is a structural database rebuild of the WPHOST.DB file.

  • Status: This allows you to suspend processing of administration tasks (very useful if you are currently rebuilding this database offline and want to keep things in sync). Pressing the Esc key takes you back to the Options menu.

  • Message Transfer Status: This menu item calls up the Message Transfer Status screen. Following are the fields you will see in the Message Transfer Status screen:

    • Outbound TCP/IP: This displays the IP address and message transfer port (MTP Port) of the domain's MTA that the POA talks to in order to transfer messages out of the post office.

    • Inbound TCP/IP: This reflects the IP address and port that the MTA is expecting the POA to be listening on for incoming traffic to the post office.

    • Hold: This is the directory where this POA queues up messages if the connection to the MTA is blocked for some reason.

    • Last Closure Reason: This shows why the POA cannot connect to the MTA. It might not tell you exactly what's wrong, but it can give you a good idea of where the problem is. As with the Admin Status dialog box, pressing the Esc key takes you back to the Options menu.

  • Cycle Log: Cycling the log dumps the current log into a file and begins a new log file. This is useful when you are getting ready to use the Configuration Options menu to list some TCP information, and you want it to be at the top of the log file for easy access later.

  • Actions: T his option calls up the Actions menu shown in Figure 8.9.

    Figure 8.9. The POA Actions menu

You are less likely to use the POA Actions menu; however, the actions available to you are great to have when you really need them. Settings include the following:

  • View MF Queues: This allows you to see, at a glance, how many files are waiting in the WPCSOUT directory structure. These files are waiting for processing by the POA. The list is dumped into the current log file.

  • Disable Auto Rebuild: This tells the POA not to attempt to rebuild damaged databases that it encounters in the course of message delivery or client/server processing.

  • QuickFinder: This calls up the four-option dialog box shown in Figure 8.10.

    Figure 8.10. The POA QuickFinder menu

  • Update QuickFinder Indexes: This option launches the indexing process. All indexes served by this POA, including the mailbox index and all library indexes, will be updated.

  • Compress QuickFinder Indexes: This merges all incremental indexes with the permanent index. The permanent index files will be renamed to reflect the time the operation was performed.

  • Update and Compress QuickFinder Indexes: This performs both of the preceding operations, beginning with the update.

  • Delete and Regenerate All QuickFinder Indexes: This deletes all the *.INC and *.IDX files in the post office\ofuser\index directory, and launches the indexing process to reindex all databases in the post office.

Warning

Kick off the Delete and Regenerate All QuickFinder Indexes option only when the POA has a lot of time to spare; for example, on a Friday night. Depending on the amount of data you have, it can take more than a day to reindex all of your data.

  • Restart MTP: The MTP process is the process on the POA that sends and receives messages from the MTA. When troubleshooting connectivity problems between a POA and the MTA on the domain above the post office, it's often helpful to restart the MTP process.

There's really not much more you could want on the POA console screen to make it easy to troubleshoot. The POA console screen, particularly on the NetWare platform, is a big help.

Undocumented POA Commands and Switches

There are a few things you can make the POA do that are not listed in the menu items. These commands are typically used by Novell's technical support personnel to resolve sticky problems, or for troubleshooting. There are other undocumented POA commands; however, the two listed here are the ones you are most likely to need for troubleshooting.

Let's take a look at these undocumented POA commands and switches:

  • Ctrl+Z (diagnostic logging keystroke): This keystroke toggles diagnostic logging on and off. Diagnostic log files are much larger than verbose log files, but can contain information that is critical to correctly diagnosing a problem (hence the name). Running the POA in diagnostic mode for extended periods is not recommended. Performance degrades slightly in this mode.

  • /IPLL-DIAG startup switch: This switch launches the POA with very detailed IP transaction logging, useful in conjunction with sniffer traces to isolate network problems.

Tip

The GroupWise POA has several other startup switches. Use the /? switch to view a listing of other common switches that the POA supports. On the Linux platform use the -help switch.


Understanding the Agent Log

The GroupWise POA is a multithreaded server application that performs large numbers of operations each second. The log files can be confusing. An entry indicating that something was received for processing might not be immediately followed by an entry indicating that the spawned process was completed.

Log Line Format

To help make sense of the log, each line in the agent log is divided into four main parts.

The first of these is the timestamp. Anyone who can read a 24-hour digital clock can make sense of thisit is in HH:MM:SS format. This is the hour, minute, and second of the day that the event in this log entry occurred.

The second part is the process number. This is more complex. The process number is typically a three-digit number identifying the process or thread that performed the operation described in this log entry. If you are trying to follow a thread in the log, you must do so by finding the next occurrence of this number. If process 118 attempts to deliver a message, and the next line indicates that process 244 encountered an error, the error was not with the message in the previous line. Look for the next occurrence of process 118 to determine whether the message was delivered.

The third part, which is not always present, is the process type. This is a three-letter string that identifies the admin engine or the message transfer engine. When the POA processes updates to the post office database (administration messages), the string is ADM. Message transfer events (connections to the MTA for transmitting or receiving messages of any type) use the string MTP.

The fourth part of the log entry is the event description. This might be short and cryptic, but after you have seen a few of these descriptions, you can easily make sense of them. It might be an error message, or it could announce the user ID of the user who just logged in.

Common Log Entries and Explanations

This section offers a look at some examples of log entries. In all of these examples, the log level was set to verbose so that the maximum amount of useful information was captured without overburdening the POA.

Message Delivery

The following sequence tracks delivery of a mail message from tkratzer to gbrown:

20:44:20 1EC Distribute message from: tkratzer
20:44:20 1EC Begin distribution to 1 users
20:44:20 1EC Distributed: GBROWN

Notice that all three entries have the same process number, 1EC. That's how you know that the transactions are related.

Administration Update

This next sequence is the result of the administrator's changing the telephone number for user ecornish:

21:02:40 237 MTP: Receiver thread started: 1 running
21:02:40 262 MTP: Received file:
WWWFS1\SYS:/CORP/CORPPO\wpcsout\ofs\2\aec15d70.001, Size: 1010
21:02:40 251 Processing aec15d70.001
21:02:40 251 Processed OK
21:02:40 255 ADM: Completed: Update object in post office -
User MFG.MFGPO.ECORNISH (Administrator: (WWW_TREE_1)
TKRATZER.AMERICAS, Domain: MFG)

It looks confusing, but only because so much information has been packed into the event description. POA server process 237, which was running the MTP subprocess of the POA, received a message from the domain MTA, and placed the message in the post office\WPCSOUT\OFS\2 directory. A POA routing process, numbered 251, looked at the header of the message and determined that the message was an administrative message. The POA routing process then moved the message from the wpcsout\ofs\2 directory to the wpcsout\ads\2 directory (this is not logged in the log file, but it is mentioned to help you understand the flow of administration messages). The routing process then tickled the POA's administration thread called ADM running as POA server process 255. The ADM process committed the phone number change to the WPHOST.DB file. The log shows that the object updated was user ECORNISH in the MFGPO post office of the MFG domain.

The code in parentheses is especially useful. With this information, you can audit your administrators, ensuring that they are accountable for the changes they make to your system. The administrator who made the change was authenticated to the WWW_trEE_1 eDirectory tree, and used the TKRATZER account in the AMERICAS context. You can also see that the operation was performed while ConsoleOne was connected to the MFG domain's WPDOMAIN.DB database.

Tip

Although you can determine who makes administrative changes, you might find that sometimes the information recorded is incorrect. What will happen is the administrative update will actually reflect the person who made changes to this object, just prior to the person who made the latest administrative change. For example, if last week Glenn Brown modified Eva's object, and then Tay Kratzer modified Eva's object, it may show that GBROWN modified Eva's object.


Best Practices

Post office agent performance is important to your users. If the agent does not have the resources it needs to quickly process client/server requests, your users will notice. The client will be sluggish and nonresponsive, and users might think their workstations have locked up. It is therefore critical that the system be built and configured so that the POA is always performing well for your users.

Carefully Considering Settings That Impact POA Performance

There are several settings that can affect the POA's performance. Many of the settings will not affect the POA's performance, if just one or two of them are poorly configured. However, the cumulative effect of several settings incorrectly configured can degrade performance. Here are several settings or conditions to watch for, and some brief detail about each of them:

POASettings

  • Generally, you want one TCP handler thread allocated for every 25 users.

  • Generally, you want one message handler thread allocated for every 50 users.

  • For our customers, we set the CPU Utilization on the Agents Settings page of the POA on a dedicated GroupWise server to 95.

  • If your post office is composed of caching users, set the Max Thread Usage for Priming and Moves on the Agent Settings page to 50%.

  • Turn off SNMP on the POA if you are not using an SNMP monitoring solution.

  • Make sure that QuickFinder Indexing happens after business hours.

  • Always enable Perform User Upkeep to happen sometime after midnight. If you do it before midnight, the task items will not advance, nor will the trash items be emptied, until users log in the next day. Make sure that your QuickFinder Indexing and your Perform User Upkeep do not run at the same time. You probably should space them out by about four hours.

  • Run scheduled events at a different time than when the QuickFinder indexing and the Perform User Upkeep run.

Post OfficeClient Options

  • Determine whether you are going to allow junk mail handling. You do not want to make the junk mail handling feature your only anti-spam solution. This is inefficient for a couple of reasons. First, the spam makes it all the way through your network, just to be rejected prior to the user getting it. Second, the POA will have to chug through all the users on the junk mail list to determine whether the message should be rejected.

  • Turn off wildcard addressing, unless you really intend for users to use this setting.

  • Consider setting user limits on mailbox size, and maximum sent message size.

  • In the Send options, consider which kind of status tracking you need. Some customers have set their status tracking to All Information. This level of status tracking can be a drag on a GroupWise system. For optimal performance, set the Send options status tracking to Delivered and Opened.

Limiting the Size of the Post Office

The first mistake made by many administrators is overloading the post office. Unfortunately, it is very difficult to determine exactly how many users can belong to a single post office. Performance depends more on what the users are doing than on how many of them there are.

In practice, GroupWise administrators have seen that having more than about 700 users in client/server (online mode on the client) on a GroupWise post office often results in poor performance.

Creating post offices with thousands of users that are in both online and caching mode is not generally feasible. If you intend to grow to a larger post office, all the users on the post office should be in caching mode.

Limiting the Size of the Message Store

Post office agent performance degrades, and memory requirements increase, as the size of the message store grows. Performance problems are intensified if users keep too much mail in their master mailboxes. For a 700-user post office, we recommend purging mail older than 180 days. This should ensure good performance. If you do not have an email retention and expiration policy in place, you might consider using a third-party archiving solution, such as GWArchive, available at www.gwtools.com; Nexic Discovery, available at www.nexic.com; or other such solutions available from Novell's GroupWise partners.

Using One Post Office Per Server

If you have a choice between putting two 350-user post offices on a single server, and putting one 700-user post office on that same server, we recommend the 700-user option. The POA will load-balance in favor of client/server threads, but if there are two POAs running on one CPU, they cannot "talk" to each other to determine the best allocation of the limited resources. Placing more than one post office (and, therefore, more than one POA) on a single file server is not recommended. That said, putting a few 100-user post offices on the same server will generally not cause problems, and is in fact a common practice. It's the larger post offices that have problems with two on a server.

As with the size of the post office, the number of post offices per server is an area where you might be able to ignore my advice and get away with itespecially on heavy-hitting hardware. Just be sure to consider our recommendations.

Dedicating the Server to GroupWise

If you have more than 200 users in the post office, don't use this server for other applications. User home directories, eDirectory authentication, APPS volumes, and web servers should be on separate hardware. Your users will grow to depend on GroupWise more than almost any other application they run. They will demand good performance out of it, so GroupWise deserves to be treated as a mission-critical application. If another application can steal CPU slices out from under your POA, your users might eventually rise in revolt.

Monitoring Your POA Through a Web Browser

The GroupWise POA can be monitored through a Web browser. In fact, you can even suspend and restart some processes on the GroupWise POA. You can find lots of information about how your POA is functioning that you cannot find out in any other manner. For example, with the web-browser monitoring interface of the POA, you can determine exactly which users are logged into the post office. You'll still find it useful to use the POA's console interface on your NetWare or Windows server, but as for monitoring the POA, nothing beats the Web-browser interface of the POA.

Simple Configuration

The GroupWise POA needs three settings tweaked in order to support HTTP monitoring of the POA:

  • An HTTP port specified

  • An HTTP monitoring username specified

  • An HTTP monitoring password for the username specified

You can configure all of these settings in ConsoleOne.

HTTP Port

To specify your HTTP port, go to the Network Address property pages of your POA object in ConsoleOne. Fill in the HTTP Port field. Fill in the HTTP port with a value that you know is unique. Don't use the same port as the client/server port or message transfer port.

HTTP Username/Password

To specify the HTTP username and password settings, go to the Agent Settings property page of the GroupWise POA object.

At the bottom of the GroupWise Agent Settings property page, fill in the HTTP username field and the HTTP password field.

Note

The HTTP username and password are not required to enable HTTP monitoring of the POA. It is highly recommended to enable the HTTP username and password feature, however, in order to secure access to the HTTP port of the POA.

Monitoring the POA with a Web Browser

Monitoring of the POA from a web browser is a particularly relevant topic for customers who run a GroupWise POA on the Linux or Windows platform. The HTML interface to the GroupWise POA is complete and powerful. It is highly recommended that you enable this feature of the GroupWise POA.

Fill in the IP address or DNS name of the server running the POA, along with a colon and the port number you specified in ConsoleOne or the startup file of the POA. For example:

http://192.168.95.101:8100

You will be prompted for the username and password; use the username and password you specified in ConsoleOne. Figure 8.11 shows the HTTP monitoring screen of a GroupWise POA.

Figure 8.11. The GroupWise POA HTTP monitoring screen

[View full size image]

When you are in the GroupWise POA HTTP monitoring screen, you'll see a bevy of information. Figure 8.11 shows only a small part of the information you can get on the POA and the server running the POA.

Tip

When you're monitoring the GroupWise POA through a browser, if you do not remember the HTTP port number, you can also enter through the client/server port. This is usually 1677. The client/server port will redirect the browser to the correct HTTP port for monitoring.

Advanced Configuration

The HTTP monitoring piece of the GroupWise POA has some powerful features that can be enabled if you want, including the following:

  • HTTP refresh interval control

  • GroupWise client version/release date flagging

To take advantage of the HTTP refresh interval control feature, you need to edit the startup file for the POA. This setting cannot be made from ConsoleOne.

To enable the switch, type the following:

/httprefresh

If you want to have the refresh take place every 20 seconds, the line would read as follows:

/httprefresh-20


Summary

This chapter discussed loading, configuring, tuning, and monitoring the GroupWise POA. This chapter also took a close look at the POA object in ConsoleOne and examined the options available from the POA's server console.


Chapter 9. Configuring the Message Transfer Agent

Every GroupWise domain must have a message transfer agent defined for it. The message transfer agent (MTA) has three major responsibilities in the GroupWise system:

  • Transferring messages between post offices and domains

  • Writing administrative changes to the domain database (WPDOMAIN.DB)

  • Transferring messages to or from gateways for transport to or from other mail systems

This chapter discusses operation and configuration of the MTA and explores link configuration for the GroupWise system. At the end of the chapter, you can find some best practices to help you design and configure your system correctly.


Loading the MTA

The GroupWise MTA requires certain information before it loads properly. Simply typing GWMTA.NLM from a NetWare server console results in an error message stating that required parameters are missing. There are two ways to provide the required parameters.

When the agent installation program ran on this server, you were prompted for some information. The installer used this information to create a startup file with all the information the MTA needs. The name of this file is the name of the domain, truncated to eight characters, followed by the .MTA extension (for example, CORP.MTA). If the installer ran more than once, the extension of the existing startup file was changed to .MT1, .MT2, and so on (depending on how many times you installed), and the new startup file retains the *.MTA extension. This is helpful if you need to review the original startup file for the MTA; note that it is not overwritten.

To use the startup file, load the MTA with the @ switch as shown here:

NetWare:

LOAD GWMTA @filename.POA

Thus, for the CORP domain, the command would be the following:

LOAD GWMTA @CORP.MTA

Linux:

/opt/novell/groupwise/agents/bin/gwmta @../share/filename.mta

Thus, for the CORP domain, the command would be the following:

/opt/novell/groupwise/agents/bin/gwmta @../share/corp.mta

Loading the MTA with Command-Line Switches

Another way to provide the MTA with the information it needs is to use command-line switches. On the Linux platform the leading slash (/) is replaced by a dash (-). Neither the parameter nor the value strings is case-sensitive for the NetWare or Windows MTA. On the Linux platform, switches and value strings are case-sensitive. A rule of thumb for the Linux MTA is to keep all switches and parameters lowercase. The only exception is the -home switch for the Linux POA. If the path to the post office's home does have any uppercase characters, this should be reflected in the home switch.

Any number of switches can be placed on the command line used to load the MTA, and they can even be used in conjunction with the @ switch described in the preceding section.

The only required switch for the MTA is the home switch, which gives the agent the path to the domain to be served. The syntax is as follows:

LOAD GWMTA /HOME=volume:\path

For a domain residing in the CORP directory on the MAIL volume of a NetWare server, the command line would look like this:

LOAD GWMTA /HOME=mail:\corp

For a domain on a Linux server, the syntax would look something like this:

/opt/novell/groupwise/agents/bin/gwmta home-/mail/corp

Learning the Switches

Almost all the switches the MTA will recognize are listed in the startup file. Any switch found in this file can be entered on the command line used to load the agent.

The section "Notable MTA Commands and Switches," found later in this chapter, includes a switch to turn off the Message Logging feature.

As indicated in Chapter 8, "Configuring the Post Office Agent," startup switches and startup files should be used only when a particular setting cannot be made in ConsoleOne. We recommend you administer the MTA as much as possible through ConsoleOne, as discussed for the POA in Chapter 8.

Configuring the MTA

Each domain object has a child object representing its MTA. Double-clicking this object from the GroupWise view (or selecting Properties when right-clicking the MTA object) opens the window shown in Figure 9.1.

Figure 9.1. The MTA object details property page in ConsoleOne

[View full size image]

The rest of this section explores each of the eight property pages available from the GroupWise tab.

The Identification Property Page

The MTA Identification property page is shown in Figure 9.1, and as you can see, there is not much critical and configurable data here. The options include the following:

  • Description: The text entered in this field is visible at the top of the agent screen on the server console. It might be useful to enter the phone number or pager number of the administrator responsible for configuring the MTA in this field.

  • Platform: This window allows you to select the server platform on which the MTA will run.

The Agent Settings Property Page

As opposed to the available agent settings for the POA, there is little to configure for the agent settings for the MTA (see Figure 9.2).

Figure 9.2. The MTA object Agent Settings property page

[View full size image]

From the property page, you control four aspects of MTA operation: scan cycles, database recovery, additional threads, and HTTP monitoring. Explanations of these settings are listed here:

  • Scan Cycle: This sets the interval, in seconds, that each normal-priority thread waits before scanning its assigned queues. The queues that the MTA scans are the WPCSIN\2 tHRough WPCSIN\7 subdirectories of the domain directory. Also, if the MTA is linking to a post office via a UNC path, this is the interval between scans of the WPCSIN\2 tHRough WPCSIN\7 subdirectories of the post office directory.

    Tip

    As you can imagine, an MTA with UNC links to multiple post offices could become seriously burdened just with polling directories if this value is set too low. Novell recommends that all post offices be linked with IP addresses to avoid this potential problem.

  • Scan High: This sets the interval, in seconds, that each high-priority thread waits before scanning its assigned queues. The high-priority queues are WPSCIN\0 and WPCSIN\1. Again, if this number is too low and there are lots of post offices linked via UNC, the MTA could be overtaxed just with file-polling.

  • Attach Retry: If for some reason the MTA is unable to connect to another server, whether via TCP/IP links or UNC mappings, it will wait for the attach retry interval to expire before attempting another connection. The default value of 600 seconds (5 minutes) is good, because mail won't wait too long in the hold directories between attempts, and the MTA shouldn't bog down with consecutive reconnect attempts.

  • Enable Automatic Database Recovery: This is the second aspect of MTA operation you'll control from this tab. If checked, this setting allows the MTA to perform a recover operation on a damaged domain database. If this is not enabled, damage to the domain database will result in the MTA's shutting down.

    If your domain databases are getting damaged regularly (probably through unstable workstations being used for GroupWise administration), you should disable this feature and resolve the problem. This will help prevent certain kinds of record loss.

  • Use 2nd High Priority Scanner: Each link the MTA must service is assigned its own threads. There are twoa high-priority routing thread and a normal, or mail, priority routing thread. If there are 10 links to be serviced, there will be 20 threads. Checking this box will spawn a second thread for high-priority routing for each link, which means you'll now have 30 threads (10 mail priority and 20 high priority). This should be used only if you have a significant number of users using the busy search feature and scheduling users off of their post office.

    If you find bottlenecks at an MTA, consider using the queue assignment or link scheduling features described later in this chapter.

  • Use 2nd Mail Priority Scanner: Like the preceding setting, this option spawns an additional thread for every link. The additional threads service queues 27. This option allows the MTA to process the 23 queues separately from the 47 queues. The end result is that messages in the 23 directories move more quickly through your MTA. Checking this option is particularly helpful for larger GroupWise systems, which have a lot of administrative changes.

  • SNMP Community "Get" String: This field is for Simple Network Management Protocol (SNMP) community strings and is not required, unless you are using a third-party SNMP product.

  • HTTP User Name/Password: These set the username and password you intend to use when monitoring your MTA through a Web browser.

Most of the settings on this page are fine-tuning settings. The HTTP username and password are very helpful when monitoring your MTA with a Web browser.

The Network Address Property Page

The information found on the MTA Network Address property page is absolutely critical to proper communication across your GroupWise system. When creating a new domain (and hence a new MTA object), you will want to immediately specify the TCP/IP address and port of the MTA. The SSL portions of this screen are not discussed in this chapter. Chapter 27, "Securing Your GroupWise System via SSL," gives detailed information on how to enable SSL on the MTA.

Warning

If the IP address of the domain file server must be changed, it is critical that the change also be reflected in the MTA object's network address panel. All other domain databases have a copy of this object record and use this information when communicating with this MTA. If the information is inaccurate, other MTAs will be unable to connect with this MTA to transfer messages.

The best way to make changes to IP addresses and ports on a live system is discussed later, in the section "Best Practices."

Utilizing the Network Address page, you can adjust various settings.

To modify the TCP/IP address, follow these steps:

1. | Click the button to the right of the field labeled TCP/IP Address.
2. | Enter the IP address or DNS name of the server on which this MTA runs.

The IPX/SPX address setting is relevant only if you use SNMP software that can access an IPX address.

Enter the message transfer port for this MTA in the Message Transfer Port field. If you are unsure of this value, use the default port, 7100. If there are multiple domains on a single server, each of the MTAs will need a unique port. Perhaps you could use sequential numbering in this case (such as 7100, 7200, 7300, and so on). It's helpful to have the MTAs end in 00 on the port. This way, if the POAs are sequential on the MTP port, they will not conflict with the MTAs. You might also need to renumber ports if there are POAs on this server that are communicating with their MTA via IP.

Tip

If you fill in the DNS address for the MTA, make sure that all the servers that house MTAs in your GroupWise system are configured to query the DNS server. On a NetWare server this means there is a RESOLV.CFG file in the SYS:ETC directory. The RESOLV.CFG file would be configured with at least two lines; for example:

domain worldwidewidgets.com
nameserver 138.67.86.51

The HTTP port is used by the MTA and the GroupWise monitor utility. This port tells the MTA which port to listen to for Web-browser monitoring. This GroupWise Monitor utility reads the HTTP port value from the domain database in order to monitor the MTA.

Important

If you enable HTTP monitoring, you will also want to enable the HTTP username and the HTTP password. To do this, go to the Agent Settings property page and fill in the HTTP User Name and HTTP Password fields. If you don't define the HTTP username and password, anyone can access the MTA's HTTP port without being prompted for authentication. Not a good thing to have wide open.

There's not much on this page, but it is essential, particularly for domain-to-domain links, that the information on this page is accurate.

The Log Settings Property Page

The Log Settings property page allows you to control the amount of information captured in the MTA log, as well as the amount of disk space that old logs consume. Let's take a look at the settings on the Log Settings property page:

  • Log File Path: By default, this field is blank. MTA logs are put in the MSLOCAL directory under the domain directory. If you choose to keep logs elsewhere, enter the path here. We do not recommend that you put logs on a separate serverperformance might suffer, and if that server goes down, the MTA will not function.

  • Logging Level: There are three menu items in this drop-down list:

    • Off: No logging.

    • Normal: The MTA tracks major events in the log, but most of the detail is gone.

    • Verbose: The log contains useful detail. This option is recommended.

  • Max Log File Age: This sets the oldest that any log file on disk can be before the MTA deletes it. The default is seven days, which is typically sufficient.

  • Max Log Disk Space: This sets the maximum amount of disk space that all the log files can consume. If the logs reach this limit, the oldest log file is deleted. If you choose to set the Max Log File Age option beyond seven days, you will want to raise this limit to make sure that you actually get to keep your oldest logs for the time you specify. Unfortunately, this can be very difficult to estimate.

Note

The MTA automatically cycles to the next log file when the current log file reaches 1024KB (1MB), just as the POA log does.

The log settings of your MTA are not a critical function of the MTA, but having log settings configured correctly sure can help when it comes to troubleshooting.

The Message Log Settings Properties Page

Message logging is an integral part of the search feature of the HTTP monitoring piece on the GroupWise MTA. With message logging enabled, you can search for messages that passed through the MTA. In GroupWise 5x, customers were discouraged from turning on message logging; however, this is no longer the case. The MTA no longer uses a proprietary database, but the message log files are simple text files. The filename is in the format of MMDD MSG.00 X, and message log files are located by default in the DOMAIN\MSLOCAL\MSGLOG directory. For example, the first log file on December 14 would be named 1214MSG.001. The MTA will cycle to a new MMDD MSG.00 X just as it does with the traditional log files.

One advantage to enabling message logging is that you can hook into a couple of report-gathering features that are available in the GroupWise monitor utility. For example, you can generate reports that will tell you how much data has been transmitted and received between two domains. This is very useful when a company has WAN links involved between the GroupWise agents. GroupWise message logging is not the terrible performance degrader that it was in previous versions of GroupWise 6.0x and below.

Figure 9.3 shows the GroupWise Message Log Settings property page.

Figure 9.3. The MTA Message Log Settings property page

[View full size image]

The Scheduled Events Property Page

There is only one kind of scheduled event that a GroupWise 6.5 MTA can run, and that is an eDirectory user synchronization event. The MTA can scan eDirectory for deltas, which are changes to eDirectory user objects that are not correctly reflected in the domain database.

Here's a plausible situation in which eDirectory synchronization is very useful. At WorldWide Widgets, users can change their phone numbers in eDirectory via a Web portal, for example, eGuide. The administrator wants those changes to be pushed down to the GroupWise address book automatically. With eDirectory User Synchronization enabled on the GroupWise MTA, the MTA searches eDirectory for changes to the user objects. Changes to the telephone number are then pushed down from eDirectory to the GroupWise directory store (WPDOMAIN.DBs and WPHOST.DBs).

A GroupWise MTA can be configured to discover eDirectory changes to users who are members of the domain that the MTA is servicing. A GroupWise MTA can also be configured to discover eDirectory changes to users who are not members of the domain that the MTA is servicing. For the GroupWise MTA to log in to eDirectory, its object must have rights to read the attributes of the eDirectory objects you want it to include in the discovery. Let's imagine that at WorldWide Widgets the administrator wants the following scenario:

  • The GroupWise MTA for the CORP domain will run eDirectory synchronization for both the CORP domain and the MFG domain.

  • The eDirectory synchronization will run once a day.

Here are the configuration steps needed to enable this setup:

1.
Connect to the CORP domain in ConsoleOne.

2.
In ConsoleOne, select Tools, GroupWise System Operations, eDirectory User Synchronization.

3.
Click the Configure Agents button.

4.
Highlight the MTA for the CORP domain and make sure that eDirectory access is enabled, as shown in Figure 9.4. Click the OK button to get back to the eDirectory User Synchronization Configuration window.

Figure 9.4. MTA eDirectory access is now enabled

[View full size image]

5.
Highlight the row representing the MFG domain, and click the Change Assignment button.

6.
Select the CORP domain's MTA as the MTA that will perform eDirectory user synchronization on the CORP domain's users. Click OK. Now, the eDirectory User Synchronization Configuration window should look similar to the one shown in Figure 9.5. Notice that the CORP domain's MTA is configured to perform eDirectory user synchronization for both the CORP and the MFG domains, as shown in Figure 9.5.

Figure 9.5. The eDirectory User Synchronization Configuration window

[View full size image]

Tip

For the GroupWise MTA to be able to access eDirectory, you must make sure that in the startup file of the MTA, you have enabled the /user and /password switches. The user must be someone with the eDirectory rights of Browse, Read, and Compare.

7.
Now go to the MTA object for the CORP domain. Edit the properties of the CORP domain's MTA.

8.
Select the Scheduled Events property page. Edit the existing eDirectory User Synchronization event, or create a new one.

9.
Give the event a name, and then select the Daily trigger. Have the event execute at a time that is outside of business hours. The event is now fully configured, as shown in Figure 9.6. Each day, the CORP MTA will search the eDirectory for changes to user objects that reside on both the CORP and the MFG domains.

Figure 9.6. The MTA eDirectory User Synchronization event

[View full size image]

Tip

If ever you want to kick off the eDirectory User Synchronization event manually, there's a hidden keystroke on the GroupWise MTA on the NetWare platform for doing so. Press the F4 function key, and you will be asked whether you want to perform eDirectory User Synchronization.

Tip

This scheduled event is enabled by default on the MTA. If you're running the MTA on a Windows server, you might need to disable this event if the NT server does not have access to eDirectory to log in to the tree. Leaving this enabled in this situation can cause problems with the MTA.

The eDirectory Synchronization feature is not necessary for some GroupWise systems, but it can be helpful for systems in which data, such as users' phone numbers, is altered without the use of the GroupWise snap-ins to ConsoleOne.

The Routing Options Property Page

The Routing Options property page enables you to override certain Internet addressing and default routing settings made at the system level. On large systems, this tool is critical to the proper administration of GroupWise Internet addressing, as well as configuration of MTA-to-MTA direct connectivity with other GroupWise systems. Chapter 34, "Creating a GroupWise-to-GroupWise Communication Solution Across the Internet," discusses when to use the settings shown on this page.

The SSL Settings Property Page

Configuring the SSL Settings property page is not discussed in this chapter. Chapter 27 gives detailed information on how to enable SSL on the MTA.


Link Configuration and the MTA

On large GroupWise systems, you will likely have to spend some time with the link configuration tool, shown in Figure 9.7, by optimizing or otherwise tweaking the connections between different domains, and between domains and post offices.

Figure 9.7. The link configuration tool is accessed via Tools, GroupWise Utilities

[View full size image]

In the example in Figure 9.7, there are two domains. The MFG domain's link is listed under direct links, and the GWIADOM domain is an indirect link. The domain to which ConsoleOne is currently connected and from which it reads the link configuration information is CORP (Primary). How do these domains communicate with one another? Are messages routed directly among all of them?

As Figure 9.7 shows, the CORP domain has a direct connection to the MFG domain. However, the CORP domain does not have a direct connection to the GWIADOM domain. Therefore, any messages that are destined from the CORP domain to the GWIADOM domain are routed to the MFG domain first.

In some customer environments, setting up indirect links between domains has some very practical purposes. For example, imagine a global firm with domains in many regions of the world. The Americas region has four domains: New York, Chicago, Los Angeles, and San Francisco. The Asian region has four domains: Japan, Taiwan, Hong Kong, and Singapore. The link speed between the Asian domains is somewhat fast. Only Japan has a somewhat fast network link to the New York office. So it is logical to have Taiwan, Hong Kong, and Singapore all connect to New York, Chicago, Los Angeles, and San Francisco through the Japan domain. The Chicago, Los Angeles, and San Francisco domains should all connect to the Asian region domains through the New York domain.

This link architecture has the following benefits:

  • The fastest network links are being used, so messages will move more quickly.

  • Slow network links are not being used, freeing up those links for traffic that's not as easily configurable, such as eDirectory synchronization traffic.

As this example illustrates, it is best to configure your link configuration records to follow your WAN network infrastructure.

Creating an Indirect Connection

Imagine you want to route messages from CORP to GWIADOM through MFG. Consider the following scenario:

  • CORP connects directly to GWIADOM.

  • The CORP MTA gets 8912 or 8913 errors (TCP timeouts), sometimes during business hours. These errors occur only when CORP is connected directly to GWIADOM.

  • MFG has no problem communicating with GWIADOM because it is in close network proximity to GWIADOM, and CORP has no problem communicating with MFG. Therefore, CORP should connect to GWIADOM through MFG.

The following steps create an indirect connection between CORP and GWIADOM:

1.
Connect to the domain whose MTA you want to affect.

In this scenario, it's the CORP domain, which is done from GroupWise system operations, under Select Domain.

2.
Select the appropriate domain object (GWIADOM, in this case). From the Tools menu, choose GroupWise Utilities, Link Configuration.

3.
Double-click the link you want to edit. In this scenario, it is the GWIADOM domain link (see Figure 9.8).

Figure 9.8. A direct link from CORP to GWIADOM

[View full size image]

Here the link type is direct. Because this is what needs to be changed, grab that drop-down menu.

4.
If you select the indirect link type, as in Figure 9.9, everything changes.

Figure 9.9. An indirect link from CORP to GWIADOM

[View full size image]

No longer are there IP addresses and ports. With an indirect or gateway connection, the only aspect to specify is the domain or gateway, respectively, through which to connect. In this scenario, the MFG domain has been used.

5.
Click OK and exit the link configuration tool.

6.
When prompted to save changes to links, answer Yes.

Indirect connections are generally most useful in larger GroupWise systems.

Overriding Links with the Link Configuration Tool

In some circumstances, it might be necessary to use the link configuration tool to override the IP address that has been specified for an MTA or POA object.

Consider the following scenario:

  • The MFG domain's MTA object is on a different IP address than the one listed in ConsoleOne.

  • For some reason, the IP address on the MTA won't change correctly. The change does not propagate, and the link is now down between the domains CORP and MFG.

With the following steps, you can override the address:

1.
Connect to the domain whose MTA needs to be affected, which in this scenario is CORP.

2.
Select that domain object. From the Tools menu, choose GroupWise Utilities, Link Configuration.

3.
Double-click the problem link that needs to be edited; in this scenario it's the MFG domain link.

4.
Check the box labeled Override.

5.
Notice that there are now new fields for the IP address and port for this link. Enter the correct IP address and port here. Figure 9.10 shows a configured override link.

Figure 9.10. Override link configuration

[View full size image]

6.
Click OK.

7.
Exit the link configuration tool, responding Yes to the prompt to save changes.

You will rarely need to use the override feature. We have used it in situations in which network address translation (NAT) is being used, and must be overridden for the sake of some domain's MTAs that cannot use the NATted address.

Configuring a Transfer Pull Link

Transfer pull assumes that two domains connect via UNC paths, but that one MTA is not going to be given any file-system rights to the other MTA's domain directory. In this situation, the MTA that does have rights has to "pull" messages from the nontrusted MTA's domain directory.

To configure this, both MTAs must have their links changed. You must give the nontrusted MTA an override link to a new UNC path. This path will be on the nontrusted MTA's server. You will give the trusted MTA a transfer pull path to this new UNC path.

Consider the following scenario:

  • MFG is the nontrusted MTA. The path it will use is \\WIDGET_MFG1\DATA\XFERPULL (on the MFG MTA's server).

  • CORP is the trusted MTA. It will use the transfer pull path of \\WIDGET_MFG1\DATA\XFERPULL.

  • The CORP MTA has already been assigned a login ID and password for the MFG server. This was done by adding the /USER and /PASSWORD switches to the startup file of the MTA.

The following steps configure the links:

1. | Make a directory under the WIDGET_CORP1 server on the DATA volume called XFERPULL.
2. | Under the XFERPULL directory, make a directory called WPCSIN.
3. | Under the WPCSIN directory, make individual directories 0 through 7.
4. | Connect to the MFG domain and highlight that domain object.
5. | From the Tools menu, choose GroupWise Utilities, Link Configuration.
6. | Double-click the link to the CORP domain. Make sure the link type is direct and the link protocol is UNC.
7. | Check the Override box.
8. | Enter the new UNC path (\\WIDGET_MFG1\DATA\XFERPULL) in the UNC Override field.
9. | Exit the link configuration tool and save all changes.
10. | Connect to the CORP domain and highlight that domain object.
11. | From the Tools menu, choose GroupWise Utilities, Link Configuration.
12. | Double-click the link to the MFG domain. Make sure the link type is direct and the link protocol is UNC.
13. | Click the Transfer Pull Info button.
14. | Enter the new UNC path (\\WIDGET_MFG1\DATA\XFERPULL) in the Transfer Pull Directory field.
15. | Enter a polling interval, in seconds. Remember that polling across a slow or nontrusted link can be a performance hit for the MTA. Sixty seconds is usually fast enough to satisfy users whose mail traverses the link.
16. | Click OK to dismiss the Transfer Pull Info dialog box, and click OK again to finish editing the link.
17. | Exit the link configuration tool and save your changes.

The MFG MTA really has no idea what is going on. The MTA is simply redirecting any messages for CORP into a directory on its own file server.

The CORP MTA, however, is doing double duty. When the CORP MTA sends to the MFG domain, the MTA sends as it normally does, by dropping files in the directory specified as the MFG UNC path. But every 60 seconds, the CORP MTA polls the new UNC path (\\WIDGET_ MFG1\DATA\XFERPULL), the transfer pull directory, to see whether MFG has anything to send.

In this example when the MFG domain needs to send mail to the CORP domain, the domain simply places the files in the XFERPULL directory on the local server. Then every 60 seconds, the CORP domain will come along and scan this directory for mail that is destined for the CORP domain. This allows the MFG domain to send mail to CORP without needing rights to the server where CORP resides.

Note

The transfer pull method is rarely used today because of the availability of TCP/IP links. With TCP/IP links, no file system rights are granted. Transfer pull is used when there is no IP communication between two domains. The Linux MTA does not support UNC connections to another domain or a post office. As such, the Linux MTA does not support transfer/pull links.

Scheduling Links with the Link Configuration Tool

Suppose you have a TCP/IP WAN link to a particular domain, and during the day there is heavy traffic on that link. You have decided that GroupWise traffic should not be sent over this connection during the day, unless there are high-priority messages, or lots of files have queued up. Here's a walk-through on this scenario:

  • The MFG domain lies across a WAN link that is exceptionally busy from 8 a.m. to 5 p.m., Monday through Friday, because of a mainframe inventory program.

  • The CORP MTA, which connects to MFG, is not to connect during the day, unless there are high-priority messages, a large volume of messages, or messages that have been waiting a long time.

The following steps help you work through this scenario:

1.
Connect to the domain to which the link schedule will apply. In this scenario, it's the CORP domain.

2.
Select that domain object. From the Tools menu, choose GroupWise Utilities, Link Configuration.

3.
Double-click the link you want to edit.

In this case, it's the MFG domain link.

4.
Click the Scheduling button to get to the Link Schedule window (see Figure 9.11).

Figure 9.11. The Link Schedule window allows you to create a link schedule for your domain

[View full size image]

You need to create two profiles. One is the default profile, which will be in force after hours. The other is the daytime profile, which will be in force during business hours.

5.
Click the Default button and click OK to dismiss the Default profile.

6.
Click the Create button to get to the window shown in Figure 9.12.

Figure 9.12. The Create Profile window, with changes made for link scheduling

[View full size image]

7.
Name this profile.

Now you are creating the profile for link scheduling during the day.

In this example, the profile is set so that high-priority queues (03) are processed immediately. Normal-priority queues (45) are processed only after the oldest item in them has waited 60 minutes. Low-priority queues (67) are processed only after the oldest item has waited two hours.

This example has also been set up so that if a total of 100 messages exist across all queues, regardless of their age, the MTA will open the link. Also, if there are 10,000KB (10MB) of files across all queues, the MTA will open the link.

8.
Click OK.

9.
With this new profile selected, drag the mouse across the schedule pane to create a rectangle.

The one in the example runs across the 8 to 5:30 block, Monday through Friday (see Figure 9.13). This is the schedule for which the selected profile will be active. During all other hours (the white space), the default profile will be active.

Figure 9.13. The Link Schedule window with the profiles created and scheduled

[View full size image]

10.
Click OK to dismiss the Link Schedule window, and click OK again to close the Edit Link window.

11.
Exit the link configuration tool and save your changes.

This is a great feature, but it's relevant only to specialized environments.


Message Transfer Agent Console Commands

The MTA runs on a NetWare, Linux, or Windows file server. It has its own interface, and this section discusses that interface. When the MTA has been successfully loaded on a NetWare server, you see the screen shown in Figure 9.14.

Figure 9.14. The GroupWise MTA console on a NetWare 6.5 server

[View full size image]

You can control the NetWare MTA, to some extent, from this screen with keyboard commands. Commands available from the main screen are the following:

  • F6: Restart

  • F7: Exit

  • F9: View Log File

  • F10: Options

You will be using these options often when troubleshooting the MTA.

Restarting and Exiting the NetWare MTA

This section offers a brief discussion about the difference between F6 (the Restart option) and F7 (the Exit option). When you press F6, you are prompted to confirm the restart. After confirmation, the agent closes its connections to other servers, stops all processing of transfer files on this server, and rereads configuration information from the domain database. The MTA does not, however, reread the MTA startup file. The MTA startup file is the ASCII file with configuration switches in it.

When you press F7, you are prompted to confirm the exit command. After confirmation, the agent closes all connections and stops processing messages, and GWMTA.NLM unloads. If you then reload the agent from the server console, the MTA will reread the startup file and the configuration information from the domain database.

The F7 keystroke does exactly the same thing that the UNLOAD GWMTA.NLM command does on a NetWare server. If you made changes to the MTA startup file, and you want them to be applied, you must use F7 to exit (or the UNLOAD command), and then reload the MTA manually.

Restarting and Exiting the Linux MTA

Generally the Linux MTA will be configured to run without a visible user interface. Like many Linux programs, the script that loads the Linux MTA supports the following command-line switches, after it has been loaded:

/etc/rc.d/grpwise start
/etc/rc.d/grpwise stop
/etc/rc.d/grpwise restart
/etc/rc.d/grpwise status

Tip

When the MTA is running as a service on a Windows server, and it has been set to interact with the desktop, the F7 option will be grayed out. This is because it is running as a service. To shut down the MTA when it is running as a service, you need to stop that service from running. Open the Services option from the Windows server control panel. From there, you can start and stop the MTA that is running as a Windows service.

The Options Menu

Pressing F10 from the main screen of a NetWare-based MTA presents you with the Options menu, shown in Figure 9.15.

Figure 9.15. The MTA Options menu enables you to look at almost all the functions the MTA performs

The following sections offer an explanation of each of these options in turn.

Configuration Status

The Configuration Status tool, shown in Figure 9.16, is one of the most powerful troubleshooting tools you have. It allows you to look at the status of the MTA's connections with other GroupWise domains, post offices, and gateways, and it tells you why those connections are down if there are problems. It even allows you to suspend connections should you want to prevent communication with another domain, post office, or gateway for some reason.

Figure 9.16. The MTA Configuration Status screen

[View full size image]

In Figure 9.16, you find four columns of information, but the interface provides no column headers. From left to right, the column headers would be the following:

  • Link Name

  • Link Class

  • Link Status

  • Link Connection or UNC path

Consider the first line of text. The link name here is CORP, and the link class is Domain. This means that this line represents this MTA's link to the CORP domain. The link status is Open, and the link path is wwwfs1/sys:\corp. This means that this MTA can successfully write to this path on the wwwfs1 file server.

In this example, this first line of text is a special one. It defines this MTA's link to its home directory. This MTA is running against the CORP domain database, servicing the CORP domain, so the Corp link shows up as the UNC path to the WPDOMAIN.DB file.

In Figure 9.17, the MFG link is highlighted and the Enter key has been pressed.

Figure 9.17. The MTA Link Options menu

Three options are presented on this menu:

  • Details: This option brings up a window showing the details for the selected link.

  • Resume: This option resumes service for this link, if someone previously suspended it, or the link was closed because of communication problems of some sort.

  • Suspend: This option discontinues service for this link. Service will not be resumed until Resume is selected or until the MTA is restarted.

Figure 9.18 shows that the link status for domain MFG is open. Here's how to check out a link. Selecting Details for the MFG link presents the screen shown in Figure 9.18.

Figure 9.18. The MTA Link Details window

[View full size image]

Here's a look at each of the fields available in this window:

  • MTP/HOME: This field shows the IP address of the MTA, or it shows the home directory, or link path, for this link. This can be a server path or it can be an IP address and port. If it is a UNC path, the line that reads MTP in Figure 9.18 will say HOME instead.

  • Hold: This field displays the directory that the MTA uses to queue up files destined for this domain if the home path is not accessible (that is, the link is down). Large numbers of files can queue up in this hold directory if the link stays down for an extended period.

    Tip

    You can easily see whether there are messages in an MTA's hold queue from the HTTP interface of the MTA under Links.

  • Pull: If you have configured the MTA for transfer pull, as described earlier in this chapter, the transfer pull path is listed here.

  • Version: This field shows the version of the domain, post office, or gateway that the MTA is connecting to. This information is required so that the MTA can properly format transfer files for older versions of GroupWise.

  • Current Status: This line indicates whether the link is open or closed.

  • Last Closed: This field displays the date on which this link was last closed. If the link has not been closed since the MTA was last restarted, this field is blank.

  • Last Opened: This field is the date on which this link was last opened. Again, it is tracked only since this MTA was last restarted.

  • Last Closure Reason: Here is a big reason for visiting this screen in the first place. The MTA will indicate why a link is closed. For example, an MTA could complain that it cannot create files, which means it has insufficient rights to the directory in question, or perhaps the directory in question does not exist.

  • Messages Written: This field shows the number of messages transferred to this link.

  • Messages Read: This field is the number of messages received on this link. If the link is TCP/IP, it will typically be 0 unless the connection is via UNC. Messages delivered to this MTA via UNC paths are not tracked on this screen.

From the information presented, you should be able to quickly determine the nature of a link problem. You will still need to perform some troubleshooting, but this screen will narrow your field of possibilities quite nicely.

Admin Status

When Admin Status is selected from the Options menu, a window similar to the one shown in Figure 9.19 appears. Some of the lines in this window allow user interaction, whereas some are purely informative.

Figure 9.19. The MTA Admin Status window

Following are descriptions of the fields in the Admin Status window:

  • Completed: This first line, listed under the Admin Messages heading, indicates how many admin messages have been successfully written to the domain database since the MTA was loaded.

  • Errors: This entry indicates how many errors have occurred when attempting to perform administrative transactions on the domain database. Errors in this column are not typically associated with domain database damage, though. They usually occur when domains are out of sync, and this domain receives a transaction that it cannot perform, such as adding a user who already exists or deleting a nonexistent user.

    Tip

    If you upgrade a GroupWise domain to a new version, after the MTA has recovered the MTA, it will report one error. This is normal, and there is no need to be concerned about this error.

  • In Queue: This line is a count of the admin messages awaiting processing. If lots of administration traffic is taking place (say, you just imported 2,000 users), you can expect a positive number here for a while. Usually it should be 0.

  • Send Admin Mail: This line is interactive. Pressing Enter allows you to toggle between No and Yes. This option governs whether the MTA sends email to the administrator of this domain when there are errors.

  • Status: There are two status lines. This one, under the Admin Database heading, tells the status of the domain database. During an automatic recovery, the database can be locked against changes. This status should always read Normal.

  • DB Sort Language: This is the language used to sort the address book.

  • Recovery Count: This is the number of times since the MTA has been loaded that the MTA has run a recovery against the domain database. This number should always be 0. If it is not, you have had domain database damage at some point (or perhaps you have manually triggered a recovery, described later in this section).

  • Automatic Recovery: This line is interactive. Pressing Enter allows you to toggle between Yes and No. In most cases, you will want to leave this set to Yes, thus allowing the MTA to recover the domain database if it encounters a structural error during transactions. If the MTA is restarted, this setting is not remembered; it is reread from the domain database. Permanent changes to this setting should be made to the MTA object from ConsoleOne.

  • Perform DB Recovery: This is another interactive line; pressing Enter here allows you to spawn a database recovery. This option can be useful when you suspect that the database is damaged.

  • Status: This second status line indicates the status of the admin thread of the MTA. This line is interactive; press Enter to toggle between Running and Suspended. One common reason to suspend the admin thread is to prevent updates from taking place during an offline rebuild of the domain database. While the fresh database is being created, you want administrative changes to be queued up. Otherwise, they will be written to the current database, which is going to be replaced.

You will most likely use the information in the Admin Status screen when troubleshooting problems with directory synchronization in your GroupWise system.

Active Log Window

The main screen for the MTA shows what appears to be an active log, but all that is logged to the main screen are global sorts of messages. To see the blow-by-blow log, you need to select Active Log Window from the Options menu.

This is the active log for the MTA. Log entries here indicate the time of the operation, the thread name that performed the operation, and a description of the operation. This chapter discusses the interpretation of the MTA logs later, in the section "Understanding the MTA Log."

View Log Files

If the information you are looking for in the MTA log is not in the currently active log, you need to select View Log Files.

Selecting one of the log files listed and pressing Enter brings up a viewing window so you can browse that log file.

Tip

It is much easier to view the log files from the HTTP interface to the GroupWise agents, rather than from the MTA console screen. You will find it more readable and interactive. You can also use the browser's Find functionality to find specific information you might be looking for when you use the HTTP option to view the log files.

Log Settings

You can use the Log Settings dialog box to change the logging level, the age of log files, and the space taken up by log files on-the-fly.

These settings are not retained after a restart, however. If you want to change the logging options permanently, make your changes from ConsoleOne, and then execute a restart (F6) on the MTA to force it to reread configuration information in the domain database.

Cycle Log

This command forces the MTA to begin writing to a new log file. This option is useful when the current log file needs to be moved or edited by another application (that is, opened in WordPad so that a Find operation can be performed).

Live Remote Status

This option lists GroupWise remote or cache client users who are connected to the MTA, along with the post offices and domains that the MTA communicates with in order to service the remote or cache client users. If you have more interest in live remote, read the section later in this chapter called "Configuring the MTA to Support Live Remote."

Edit Startup File

This option brings up the startup file for the MTA. You can enable and configure switches from the MTA's startup file. It is best to configure the MTA through ConsoleOne rather than through switches in the MTA. The only switches you might want to add are the "undocumented" switches mentioned in the next section.


Notable MTA Commands and Switches

There are several console command-line options that offer functionality that is not documented in the GroupWise MTA interface.

These are the commands and switches:

  • F4 or Ctrl+D keystrokes: These keystrokes execute an immediate eDirectory user synchronization operation. If you use these keystrokes while MTA is running, you will be presented with a confirmation prompt.

  • /TCPINBOUND-X: The default number of inbound connections that the MTA can have is 40. With the TCPINBOUND switch, you can increase this setting. One customer of ours with a very busy MTA has this setting set to 150. An MTA that has been configured to communicate with a lot of other MTAs, or an MTA that communicates with other MTAs over a slow WAN link, is most likely to need this setting increased beyond the default of 40, which is just hard-coded in the MTA.

  • /TCPWAITDATA-X: This setting is for the default time in seconds that an MTA will wait for data transmission from an established connection with another MTA. The hard-coded default for this setting is 20 seconds. An MTA that has been configured to communicate with other MTAs over a slow WAN link is most likely to need this setting increased beyond the default of 20 seconds.

  • /TCPWAITCONNECT-X: The MTA attempts a connection four times consecutively. If it fails all four times, it reports an error, and then waits for 10 minutes before it tries again. During each attempt, the MTA will pass the /tcpwaitconnect value (or the default of 5 seconds if no value was provided) to the TCP/IP stack. This is how long each attempt will try to establish the connection. Therefore, if the /tcpwaitconnect switch is set to 10 seconds, the MTA will attempt the connection four times in a row, each time instructing the TCP/IP stack to wait for 10 seconds before timing out. If all four attempts fail, an error is reported. This means that in this setting, it would be as much as 40 seconds before the MTA reported that it was unable to successfully connect to another MTA. It will then wait for 10 minutes before it tries again. It will do this indefinitely.

  • /TCPTRUNKWIDTH-X: By default, a GroupWise MTA can open only four connections to another MTA. Each connection is used to send a message file with. If you were to increase this setting to 10, for example, and if a GroupWise MTA suddenly has 10 messages to send to another MTA, it might open 10 connections to that MTA.

The /TCP... switches are fine-tuning features that you are most likely to use in larger GroupWise systems.


Understanding the MTA Log

The MTA keeps two kinds of logs. We'll refer to them as the MTA log and the Message Logging system. This section focuses on the MTA log, which keeps track of the actions performed by the MTA, including error messages, administration updates, and connections to other GroupWise agents.

Message Logging is a system whereby messages are tracked in a series of text files that are updated by the MTA. The tool for utilizing this information is the message-tracking feature of the HTTP monitoring piece on the GroupWise MTA.

You can browse the MTA logs from the MTA console using the View Logs tool under the Options menu. This tool does not allow for searching, however, and might be less convenient for you than using the HTTP interface of the MTA, which allows for detailed searches, or your favorite word processor.

MTA logs for a given domain's MTA are found at the root of the domain MSLOCAL directory. The log files have names such as 0125mta.003, which indicates the month and day on which the log file was created. The 003 in this example indicates that this was the third log file created, and of course, the filename shows that it was created on January 25.

If a log file is a 0-byte file, the MTA is probably currently working with it, and you will not be able to open it without using the Cycle Log command from the Options menu.

The Top of the Log File

At the top of each log file, the MTA writes the settings that it is running with. These settings, as discussed at the beginning of this chapter, could have been passed to the MTA through the command line, the MTA startup file, or the domain database.

Following is a look at a sample log file. Following are log entries from the MTA for the CORP domain.

General Settings

These first few blocks of text tell which domain the MTA is running against, what the Internet addressing and routing settings are, and some of the other general settings.

Following are the beginning lines of a sample MTA log:

23:00:17 0D7 CORPPO: Post office now open
23:00:17 0D7 MFG: Domain now open
23:00:17 0D7 GWIADOM: Domain now open
23:00:17 0CA LOG: Opening new log file: 0520mta.004
23:00:17 0CA General Settings:
23:00:17 0CA  Domain Directory:       wwwfs1/sys:\corp
23:00:17 0CA  Work Directory:        wwwfs1/sys:\corp\mslocal
23:00:17 0CA  Preferred GWIA:        GWIADOM.WWWGWIA
23:00:17 0CA  Default Route:
23:00:17 0CA  Known IDomains:        *wwwidgets.com
23:00:17 0CA  Allow Direct Send to Other Systems:   No
23:00:17 0CA  Force Route:              No

The last few settings deal with Internet addressing (covered in Chapter 16). Internet addressing has been enabled on this system. The preferred GWIA and default routing domain are listed, and then each of the IDOMAINs defined on this system is listed with a preceding asterisk.

Following is the last part of an MTA log, just after the MTA has started up:

23:00:17 0CA Error Mail to Administrator:        No
23:00:17 0CA Display the Active Log Window Initially: No
23:00:17 0CA eDirectory Authenticated:      Yes MTA.CORP.WWW.AMERICAS
23:00:17 0CA eDirectory User Synchronization:      Yes
23:00:17 0CA Admin Task Processing:           Yes
23:00:17 0CA Database Recovery:             Yes

The preceding are some of the operational settings for the MTA. This MTA has been authenticated to the directory, and eDirectory user synchronization is on. The admin thread is running, and if the MTA encounters domain databases damage, it will attempt to repair it.

TCP/IP Settings

An important part of your troubleshooting, should you have problems getting the MTA to "talk" to other GroupWise agents, is found here in the TCP/IP settings portion of the MTA log:

23:00:17 0CA TCP/IP Settings:
23:00:17 0CA  Maximum Inbound TCP/IP Connections:    40
23:00:17 0CA  TCP Port for Incoming Connections:     7100
23:00:17 0CA  TCP Port for HTTP Connections:       0
23:00:17 0CA  HTTP Refresh Rate:             60 secs
23:00:17 0CA TCP/IP Connection Timeout:      5
23:00:17 0CA TCP/IP Data Timeout:         20

The IP address of the MTA is not given here, because this parameter is defined at the server level. The inbound port is reported here, however. Also significant are the connection timeout and data timeout settings. These settings tell how many seconds the MTA will wait on an attempted connection or transmission. The values here are the defaults and can be changed with the /tcpwaitconnect and /tcpwaitdata switches in the MTA startup file.

Logging and Performance Settings

Here are the performance and logging settings for this MTA:

23:00:17 0CA Performance Settings:
23:00:17 0CA  Additional High Priority Routing Thread:  No
23:00:17 0CA  Additional Mail Priority Routing Thread:  No
23:00:17 0CA  Low Priority Scanning Cycle:        10 Seconds
23:00:17 0CA  High Priority Scanning Cycle:       5 Seconds
23:00:17 0CA Message Log Settings:
23:00:17 0CA  Message Log Directory:   wwwfs1/sys:\corp\mslocal\msglog
23:00:17 0CA  Track Messages:              On
23:00:17 0CA  Track Delivery Reports:          On
23:00:17 0CA  Track Status Reports:           On
23:00:17 0CA  Track Admin Traffic:            On
23:00:17 0CA  Correlate Delivery Reports:        On
23:00:17 0CA  Collect Extended Information:       On
23:00:17 0CA  Expire Records after How Many Day:     7
23:00:17 0CA  Message Log Database Size:         23552 bytes
23:00:17 0CA  Message Logging Enabled:          Yes
23:00:17 0CA Scheduled Event Settings:

In the performance settings section, it shows that there are no additional threads that have been spawned, and the scanning cycles for the MTA queues (WPCSIN\<0-7>) are every 5 seconds for the high-priority queues and 10 seconds for low-priority queues.

Finally, the log says that message logging is enabled, and indicates what the message log settings are set to.

The Body of the Log

Each line in the body of the MTA log is divided into three major sections: the timestamp, the process, and the statement. For example:

16:13:56 MTP: MFG-ipS0: Connection established. 137.65.55.211

In this example, the timestamp reads 16:13:56 (56 seconds after 4:13 p.m.), the process is MTP, and the statement is MFG-ips0: Connection established. 137.65.55.211.

The Process Column

If you are to make sense of the MTA log, you must first understand the acronyms and abbreviations in the process column. This section defines them:

  • DIS: The dispatch process is responsible for dispatching other processes. You will see the DIS process when the MTA receives a restart command.

  • RTR: The router process is responsible for moving files from one directory to another, as part of the whole message transfer operation. It is also the receive process when another MTA or POA transmits a file to this MTA via TCP/IP. If you have UNC links, RTR acts as both the send and the receive process, because RTR handles movement between directories.

  • MTP: The message transfer process is responsible for connecting to another GroupWise MTA or POA and transmitting a message file to it via TCP/IP. This is the send process for the MTA.

  • MLG: The message logging process is responsible for writing to the message log database. Even with message logging disabled, you will see the MLG process announcing the results of RTR and MTP operations.

  • SCA: Th e scanner process is responsible for polling gateway directories under the domain directory, as well as any post office directories where TCP/IP connectivity has not been set up.

  • ADM: The administration process is responsible for updating the domain database with any GDS (GroupWise Directory Services) information that is being propagated around the system. Add a user while connected to one domain, and you should see the ADM process on every other domain's MTA add that user there. (You'll also see the ADM process in the POA logs as the user is added to the post office database.) On occasion, you might see the Administration thread report itself as ADA or ADS.

  • SNMP: The Simple Network Management Protocol process shows up when SNMP is enabled. It periodically announces that it has obtained the necessary parameters to publish MTA operational information to any SNMP-aware query agent on the system.

The MTA log files are very helpful when troubleshooting, particularly when determining whether administrative messages are being processed.


Configuring the MTA to Support Live Remote

Prior to the GroupWise 5.5 Enhancement Pack, the MTA never "talked" directly with the GroupWise client. Now, however, the GroupWise MTA can communicate with the client, if the client is a GroupWise 5.5 Enhancement Pack (5.5E for short) or GroupWise 6.5 client running in remote mode. This might sound like a funny thing for an MTA to do, but it has an application in some environments. This feature was added to allow GroupWise systems to better support remote-user connections over the Internet.

End users increasingly have their own connections to the Internet. It is natural for GroupWise users to want to connect to their organization's GroupWise system in order to download their GroupWise mail to their GroupWise remote mailbox. Prior to GroupWise 5.5E, the only way administrators could enable this functionality was to allow Internet hosts to contact each post office's POA and speak with the POA at any port. This raised all sorts of security issues. Because of this, most organizations opted not to allow users to access their POA from outside their organization's firewall. Now the GroupWise 6.5 POA supports connectivity via proxy server. For more information on configuring the POA to support proxy server connectivity, read Chapter 8.

The GroupWise MTA can accept a connection from a GroupWise client at the live remote port configured for the MTA. The GroupWise MTA can then open a virtual live remote session with the POA that supports the user's post office. The effect then is that system administrators can tell users that if they have a connection to the Internet, they can configure GroupWise to connect to MTA.WORLDWIDEWIDGETS.COM using port 8100.

The MTA must have two lines enabled in the startup file of the MTA:

/liveremote-port number
/lrconn-# of connections

The first line specifies the port that the MTA will use to listen for live remote connections. The second line specifies the maximum number of simultaneous live remote connections that the MTA will allow. Each remote user will require one connection for the duration of their upload and download sequence.

For the MTA to be able to support live remote, every link between this MTA and the rest of the system must be a TCP/IP link. There can be indirect links, but the entire path must be TCP/IP, all the way down to the POA. This applies even if your POA and MTA are on the same file server.

Take the following scenario:

  • USERA is the live remote user.

  • POSTOFFICEA is USERA's post office.

  • DOMAIN1 is USERA's domain.

  • DOMAIN2 is another domain in the GroupWise system whose MTA is configured to receive live remote connections.

The message flow will run as detailed here:

  1. USERA establishes a live remote connection with the DOMAIN2 MTA.

  2. The DOMAIN2 MTA establishes a live remote connection with DOMAIN1 on behalf of USERA.

  3. The DOMAIN1 MTA establishes a live remote connection with the POSTOFFICEA POA.

  4. The POSTOFFICEA POA accesses the information store on behalf of USERA and passes responses back along the live remote chain to the user.

Note

Live remote connections can be monitored on the MTA. The DOMAIN2 MTA will register USER1 as a live remote user. The MTA will also show a domain link to DOMAIN1 under F-10, live remote status. The DOMAIN1 MTA will register DOMAIN2's MTA and POSTOFFICEA as live remote connections under F-10, live remote status. The POSTOFFICEA POA will register USER1 in the log as the live remote user.

The GroupWise remote client does not need a special kind of live remote connection type. GroupWise remote client simply specifies another TCP/IP connection as though the MTA that is listening for live remote connections is a POA.


Best Practices

Following are some practices that have been observed to improve the performance and stability of the GroupWise MTA. They are not hard-and-fast rules, however, and anything published by Novell should likely take precedence.

System Design

Keep in mind that you can have an MTA only where you have a domain. This means that if your system has some natural transfer points (such as on the segment with an edge-router, or at the firewall), you might want to consider putting a domain there so that there will be an MTA at that point.

Assume that you will be building a large system and will be using occasional indirect connections. Here are a couple of rules of thumb:

  • Avoid putting any post offices under the primary domain, and don't use the primary domain as a hub for indirectly connected domains.

  • If you have more than one domain on a LAN, those domains should all connect directly via IP. The MTAs can handle this easily. Thus, LAN connections should be mesh style.

  • If you have multiple LANs as part of a wide area network, consider having one domain at the edge of each LAN acting as a hub for indirect connections between that LAN's domains and others.

  • If you have busy gateways (such as the GWIA, which will be covered in the next chapter), you might want to consider devoting a domain (and, therefore, an MTA) to those gateways.

Remember, even though MTAs can communicate directly with any other MTA with a valid IP address, this is not always the best way to connect, especially where there are many router hops between them. Because packets are going to be stored and forwarded on these long routes, you should consider having the MTA store and forward the messages (by using indirect connections). This way you will be less likely to have problems with TCP connection timeouts, and your message transfers will be more efficient.

TCP/IP Versus UNC Links

TCP/IP links between MTAs or between the MTA and the POA are always preferred. This is true even when the MTA and the POA are on the same server. Here's why: When a link between the MTA and the POA is UNC, messages are queued, and then discovered via a polling cycle. The queuing and polling process causes messages to flow at a slower rate than when messages are sent via TCP/IP. The Linux MTA will support only TCP/IP links.

Moving MTAs to New IP Addresses or Ports

First of all, if you are moving an MTA to a new IP address, it is probably because you are moving the entire domain directory to a new server. If that is the case, review Chapter 20, "Troubleshooting Message Flow," for the complete procedure.

Perhaps, though, all you are doing is moving the file server to a new LAN segment and assigning it a new IP address. Here is the procedure you should follow:

1. | Connect to the domain that is being moved.
2. | Change the MTA object's network address to reflect the new address or port. Connections between other domains and this one will now start to drop off. Other domains, and this domain's post office, will show this domain as closed.
3. | Unload the MTA.
4. | Move the server to the new address and/or port, making the appropriate address or port changes at the server level.
5. | Reload the MTA. Check the connection to this MTA from other MTAs on the system, and from this domain's post office's POAs. The connections should begin opening, now that they "see" this MTA at the new address and/or port.

These are just a few simple steps, but they are essential for connectivity.

Tuning the MTA

Typically, a busy MTA needs little tuning to keep up with its queues. If TCP/IP links are used exclusively, the MTA will not need to waste CPU cycles polling or maintaining idle connections and will have the resources it needs.

You might find, however, that some types of messages need to be moved faster than others. Remote users and users making busy searches both use the high-priority queues. To weigh these queues a little more heavily, check the Use 2nd High Priority Router box found on the Agent Settings tab of the MTA detail window. This will spawn an additional thread for the 0 and 1 subdirectories. The more connections the MTA services, the more threads will be spawned. If the server is having trouble keeping up with queues, this will mean that the mail priority queues (27) will back up even further, whereas the 0 and 1 are processed more quickly.

On large systems, an MTA on a Pentium IIclass server should be able to process at least 100,000 messages each day without noticeable backups in any of the queues. Some administrators have seen MTAs that process three times that many messages in a day.


Monitoring Your MTA Through a Web Browser

Just like the GroupWise POA, the GroupWise MTA can be monitored through a Web browser. Using the HTTP interface of the MTA can greatly enhance your capability to troubleshoot and maintain your GroupWise system. It will be to your advantage to become very familiar with all the various components you can review and monitor via the HTTP port of the MTA.

Simple Configuration

The GroupWise MTA needs three settings tweaked in order to support HTTP monitoring of the MTA:

  • An HTTP port must be specified.

  • An HTTP monitoring username must be specified.

  • An HTTP monitoring password for the username must be specified.

All of these settings can be configured in ConsoleOne.

HTTP Port

To specify your HTTP port, edit the MTA object in ConsoleOne and go to the Network Address property page. Fill in the HTTP port as shown in Figure 9.20.

Figure 9.20. Specifying the HTTP portit must be unique

[View full size image]

Fill in the HTTP port with a value that you know is unique. Don't use the same port as the message transfer port; otherwise, your MTA will not be able to listen on the MTP port, and all inbound connections will fail to this MTA.

HTTP Username/Password

To specify your HTTP username and password settings, go to the Agent Settings property page of the GroupWise MTA object. At the bottom of the GroupWise Agent Settings property page, fill in the HTTP User Name and HTTP Password fields.

Monitoring the MTA with a Web Browser

Fill in the IP address or DNS name of the server running the MTA, along with a colon and a port name. For example:

http://137.65.55.211:8100

You will be prompted for the username and password with a dialog box.

After you are in the GroupWise MTA HTTP monitoring screen, you'll see a bevy of information. Figure 9.21 shows just one of the screens in the GroupWise MTA HTTP monitoring screen. Once again, the HTTP interface of the MTA offers a wealth of information that can help you better maintain and troubleshoot your GroupWise system. It is to your advantage to become familiar with all the options on the MTA's HTTP interface.

Figure 9.21. MTA HTTP monitoring

[View full size image]


Summary

This chapter covered all aspects of the GroupWise message transfer agent, from the details window found in ConsoleOne to the troubleshooting features at the MTA's server console screen. This chapter also discussed the link configuration tool and walked you through its use.


Chapter 10. Installing and Configuring the GroupWise Internet Agent

The GroupWise mail format is a proprietary format; although GroupWise supports many open standards, it is not an open system. Due to its proprietary format, translation is required in order to communicate with other systems.

The GroupWise Internet Agent is the most popular translator for GroupWise, because it allows GroupWise users to send email messages to recipients via the Internet. It does much more than that, however. It also provides access to the GroupWise system by supporting five different open-standard protocols.

This chapter looks at the architecture of the GroupWise Internet Agent and the protocols it supports. It also explores the installation, configuration, and operation of the GroupWise Internet Agent, otherwise known as the GWIA.


GWIA Architecture

GWIA architecturethe way in which the GWIA works with the rest of the GroupWise systemis best understood in terms of general gateway architecture. All GroupWise gateways perform one or more of the following functions:

  • Translation

  • Transport

  • Mailbox access

The functions performed by the gateway determine the way in which the gateway connects to the rest of the system. The GWIA performs all three of these functions. The following sections look at each of the functions in turn.

Translation

The GWIA translates messages from Simple Mail Transfer Protocol (SMTP) format or Multipurpose Internet Mail Extensions (MIME) format into GroupWise format. It also translates GroupWise messages from the proprietary GroupWise format into SMTP or MIME format. This allows messages sent by GroupWise users to be read by users of email systems that can receive SMTP or MIME email messages.

Note

Other gateways that perform translation include the GroupWise API gateway and the GroupWise gateways for Exchange, Notes, and the Messaging Architect's GWFax software.

The translation function requires that the GWIA receive messages from the GroupWise system. The message transfer agent (MTA) handles this by dropping Internet-bound messages into the GWIA's input queues. When messages are sent to the GroupWise system from the Internet, the MTA transfers those messages after the GWIA has translated them into GroupWise format.

Transport

Translated messages originating in the GroupWise system must be transported to the correct mail host on the Internet. The GWIA performs this function independently of the GroupWise MTA. The GWIA functions as a sendmail host, which means it can communicate with any other sendmail host on the Internet (assuming that a connection is established).

This transport is performed in TCP/IP through port 25, the industry-standard sendmail TCP port. The GWIA performs the appropriate domain name system/service (DNS) lookup to locate the recipient's mail host, and then connects and transfers the translated message. For inbound messages, the GWIA is always "listening" for similar connections from other sendmail hosts.

Mailbox Access

The GWIA can give users access to their mailboxes from alternative clients, such as Eudora, Netscape Messenger, or Microsoft Outlook Express, as well as other POP3 clients on handheld computers. The GWIA supports two forms of mailbox access: Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP4). The GWIA also allows users to access the GroupWise address book via the Lightweight Directory Access Protocol (LDAP).

To do this, the GWIA must be able to connect directly to the users' post offices. This can be accomplished by the GWIA talking directly to the post office based on UNC direct access, or by using TCP/IP to the Post Office Agent (POA). Typically and preferably, the GWIA connects to the POA in client/server mode for every user who needs POP3 or IMAP4 access and thus acts as an intermediary between the POA and the third-party mail client.

LDAP address-book access is provided a little differently. The GWIA reads the necessary address-book information directly from the domain database. The GWIA is hard-coded to look to its parent domain directory for the necessary domain database file.

Architectural Summary

When the GWIA is functioning in its capacity as a sendmail host (translation and transport), it connects with the GroupWise system via the MTA and standard file-polling. When the GWIA functions as a POP3 or IMAP4 host (mailbox access), it connects with the GroupWise system via the POA in client/server or direct access mode. When the GWIA functions as an LDAP host, it connects with the GroupWise system via a UNC mapping to the domain database.


Installing the GWIA

The GWIA is not installed, by default, when you create your GroupWise system. It is not required for users to be able to send messages to each other. Of course, because it is required for users to send Internet email, a GroupWise system without a GWIA is a little bit like having a Harley that you use only to walk your dog. That's an interesting picture!

This section walks through the process of installing the GWIA so that users can send email to their biker friends in Sturgis, South Dakota, or anywhere else in the world. First, though, let's lay down some prerequisites for the server that will run the GWIA:

  • The GWIA server should have access to the Internet, unless the GWIA will relay to another SMTP host.

  • The GWIA must have a way to resolve Internet domain names to Internet addresses. The server that houses the GWIA needs to be configured to point at a DNS server. On a NetWare server that means there is a RESOLV.CFG file in the SYS:ETC directory. The RESOLV.CFG would looking something like this:

    domain wwwidgets.com
nameserver 137.65.55.200
nameserver 137.65.55.201

  • The GWIA should be configured as an Internet host, accessible from the Internet. On a NetWare server, this means that the SYS:ETC\HOSTS file has a listing of the server's IP address and its fully qualified Internet domain name. The Internet domain mentioned in the Internet domain name should match the Internet domain mentioned in the RESOLV.CFG file mentioned earlier. For example:

    137.65.55.211 SMTP.WWWIDGETS.COM

  • The GWIA should be running on a server with plenty of horsepower; it's good to have plenty of disk space, but not like a post office. The GWIA keeps messages in a holding queue only for a short time.

  • Your DNS administrator will want to make three DNS records: an A record, an MX record, and a PTR record for the server that is running the GWIA. An A record is an Address record pointing to the server running the GWIA. This helps establish the server on the Internet as a member of the Internet domain that the server is a member of. In our example, the Internet domain is wwwidgets.com. An MX record indicates to other SMTP hosts which host in the wwwidgets.com Internet domain to try to send SMTP messages through. So, for example, if the Internet domain name is WWWIDGETS.COM and the aforementioned server had a name of SMTP.WWWIDGETS.COM, the MX record would point to SMTP.WWWIDGETS.COM as being the Internet host that has the capacity to receive SMTP messages from the Internet for the Internet domain WWWIDGETS.COM. A PTR or Reverse Address Lookup record translates the public IP address of the server back into the server name; for example, 134.45.67.89 will be translated to SMTP.WWWIDGETS.COM. This way, a receiving SMTP server can check the validity of your server credentials, and some servers might refuse an SMTP session from your server if this PTR record does not exist or is not configured properly. The GWIA also supports this feature when you check the option Reject Mail If Sender's Identity Cannot Be Verified, as described later in this chapter.

Following are the steps to install a GWIA on the NetWare platform:

1.
First, locate the GWIA installation program.

It is found in the GWIA directory, under the INTERNET directory at the root of your GroupWise 7 Software Distribution Directory (SDD) or on the GroupWise 7 Administration CD.

2.
Run INSTALL.EXE under the SDD\INTERNET\GWIA directory.

The License Agreement screen comes up, followed by the welcome screen, which explains what this installation program is going to do.

3.
Click Next.

Next comes the prompt for the software platform screen. These instructions will be for installing the GWIA on the NetWare/NLM platform.

4.
After making the platform selection, click Next.

The installation needs the paths for the NLMs and the NetWare load script (it's referring to an *.NCF file) that the GWIA will use. This will generally be the system directory on the SYS volume of the server where the GroupWise domain that owns this GWIA resides. However, if you are using Novell Clustering Services, you might want to install this software to a different path of your choosing, on a clustered volume. You can also update the Autoexec.ncf file, or cluster-enable the GWIA install.

5.
After making the code location selection, click Next.

6.
At the Server Information screen, indicate the IP address or DNS address for the GWIA. When installing the Linux GWIA, you need to fill in both the IP address and the DNS address fields. Also, indicate the Message Transfer Port for the GWIA. This is the port that the GWIA listens on for messages coming in from a GroupWise MTA within the GroupWise system. For those familiar with how the GWIA worked in the past, this is a difference with the queue-based method of the past. This new GroupWise 7 feature is discussed more fully in Chapter 16, "Internet Addressing."

7.
After specifying the Server Information, click Next.

8.
The GWIA, like all GroupWise agents, can be monitored from a Web browser. In the next installation step, you will be prompted for the port that the GWIA should listen to for Web-browser monitoring requests, as well as the username and password to use. We recommend skipping this step (or not checking the option to enable the Web Console) and entering this information from ConsoleOne instead.

At this point, the installation asks whether the GWIA is going to send directly to the Internet or whether it is going to use a relay host (see Figure 10.1). Relay hosts are commonly used on large, heterogeneous systems in which Internet access must be tightly controlled at the firewall.

Figure 10.1. Choosing between direct connection to the Internet and connection via a relay host

[View full size image]

9.
If a relay host is needed, provide the installation program with the IP address of the relay host machine, and click Next.

When you click Next, the install wizard will check for Internet connectivity either to the Internet or to the relay server you specified. If the server where you are installing the GWIA agents does not have connectivity, you will receive a warning about this. You can continue the install by selecting the option I Will Fix This Problem Later. Just remember to come back and fix the problem.

You might also be prompted about no DNS name resolution if the server is not properly configured to talk to a DNS Server to resolve Internet names. Once again, you can continue the install by selecting the option to fix this problem later.

10.
In the next window, you need to indicate which GroupWise domain to connect the GWIA to.

You should have made this decision well in advance of this step, because in step 4 you selected the server to which you are installing the software. The GWIA will be most efficient if it runs on the same server on which the GroupWise domain resides. This server should also be running the GroupWise MTA for that domain. The installation also prompts for a name of the subdirectory for the GWIA. The default is GWIA. Because that name is pretty intuitive, it's a good default.

11.
In yet another case of intuitive naming, the installation asks for the name of the object that will represent the GWIA in the GroupWise system and in eDirectory (see Figure 10.2). This object will appear as a child object of the domain selected in an earlier step. You can name it GWIA or some other name that works for you, such as SMTP.

Figure 10.2. Naming the GWIA object

[View full size image]

12.
After clicking Next, you are prompted for the Internet domain name that the GWIA should listen asfor example, wwwidgets.com. The value you enter here is added to the Foreign ID field on the GroupWise property page of the GWIA. If your GWIA will listen for several Internet domain names, just enter the most popular one in this field, and later you can add the others. Figure 10.3 shows this installation screen.

Figure 10.3. Here, you enter the host portion of your Internet domain name

[View full size image]

When you click Next, the install routine will check for DNS entries for this domain name. If none is found, you will be warned about the problem. Once again, you can continue the installation by choosing to fix the problem later.

13.
The Linux-based GWIA install requires some additional information in order to install the GWIA. Specifically, you are asked for LDAP authentication so that the GWIA can be put into the Novell eDirectory tree. The directions are clear enough in the wizard, but installing the GWIA successfully may be tricky without a few tips. Here they are:

  1. The IP address you specify for the LDAP server must be running the LDAP Agent for eDirectory. On a NetWare server this is the module called NLDAP.NLM. If you are pointing to a Linux server running eDirectory, most likely LDAP is running automatically as a result of eDirectory being loaded.

  2. It is best to indicate an IP address to a server that hosts a replica of the partition that houses the object for the GroupWise domain that will own the new GWIA.

  3. The LDAP settings for a particular eDirectory server are kept in the two objects called LDAP Group - servername and LDAP Server - servername.

  4. Authenticating to the LDAP server when you create the gateway can be done securely; however, in most environments the effort to do this is not worth it. It is generally easiest to allow for clear text password authentication via LDAP, simply so that you can install the new GWIA gateway object.

  5. On the LDAP Server object make sure that SSL/TLS is not required for authentication.

  6. On the LDAP Group object allow for Clear Text Password.

  7. To reload NLDAP on a NetWare server, do the following:

    UNLOAD NLDAP
LOAD NLDAP

  8. To reload NLDAP on a Linux server, do the following:

    /etc/rc.d/ndsd restart

14.
With the Linux-based GWIA install, when you specify the eDirectory location of the domain that will own the gateway object, there is a browse button for browsing the eDirectory tree. We've found that in some environments browsing for the domain will cause the installation software to quit. If this happens to you, just enter the eDirectory object location by typing it in; for example, cn=ITS,ou=CORPOU,o=WWW.

15.
Armed with all the information provided during the installation, the wizard is now ready to actually install something. If you reach this point and decide you want to change something, you can use the Back button as many times as you want. When you are ready, click Install.

When the installation is done, you have the option to launch the GWIA. However, consider waiting on launching the GWIA until you have it completely configured. It might not be able to correctly send Internet email, but it is up and running. If, during the installation, problems came up that you decided to fix later, now might be a good time to unload the GWIA so that it does not begin generating undeliverable messages.


Loading the GWIA

The preceding two chapters discussed how the message transfer agent and post office agent must be provided with certain startup parameters in order to load correctly. The GWIA needs the same sorts of parameters, but they are not provided to the GWIA the same way they are to the MTA or POA. For the GroupWise MTA and POA, most of the settings dealing with how the MTA or POA is configured are housed in the WPDOMAIN or WPHOST databases. The startup file for most MTAs and POAs has only one switch activated, the /home= switch. The GWIA is very different. Most of the GWIA's settings are not contained in the WPDOMAIN.DB file; they are contained in a file called GWIA.CFG. The following sections explain how the GWIA is configured.

If you have not finished configuring your GWIA, you might want to wait to load it a little later. Many of the configuration changes you make to the GWIA will just cause the GWIA to automatically reload and reread its configuration information. Some settings do not cause the GWIA to reload, so the GWIA must be brought down and then loaded again.

To load the GWIA after it has been installed and configured, enter the following:

NetWare:

GWIA

Novell has very thoughtfully provided an NCF file for the GWIA, called GWIA.NCF.

No startup parameters need to be passed to the GWIA manually, because it is hard-coded to look in its startup directory (typically SYS:\SYSTEM) for a file named GWIA.CFG. In the case of the NCF file, the GWIA was passed a parameter telling it where to look for the configuration file, but it wasn't necessary.

This assumes, however, that you are using the default installation directory for the GWIA (SYS:\SYSTEM on the server where the domain resides). If you need to move the GWIA to another directory or to another server, you might have some extra work to do before it will load correctly.

Linux:

/etc/rc.d/grpwise start


Understanding GWIA Configuration Files

The GWIA.CFG file should be in the same directory as the GWIA.NLM file on NetWare servers. On a Linux server the gwia.cfg is typically in the /opt/novell/groupwise/agents/share directory. This is just a regular text file that you can view with any editor.

When you make changes to the GWIA from ConsoleOne, the GWIA configuration snap-ins must find the GWIA.CFG file in order to allow you to make configuration changes to the GWIA. The GWIA configuration snap-in finds the GWIA.CFG using the following architecture. When you installed the GWIA, a little text file called EXEPATH.CFG was created. This file is found in the DOMAIN\WPGATE\GWIA GATEWAY DIRECTORY. The EXEPATH.CFG file's sole purpose is to point the ConsoleOne snap-ins to the path of the GWIA.CFG file, which typically resides in the SYS:SYSTEM directory on a NetWare server.


Configuring the GWIA

Just like the MTA and POA, the GWIA should be configured using ConsoleOne. However, there are many advanced switches for the GWIA that are not mapped to ConsoleOne snap-ins for the GWIA. These switches must be manually added to the GWIA.CFG file. The GWIA object is found under the domain object under the Gateways drop-down list in ConsoleOne. After right-clicking the GWIA object, selecting Properties, and then selecting the GroupWise tab, you should see the Identification property page shown in Figure 10.4.

Figure 10.4. The GWIA object Identification property page is where you configure general information about the GWIA

[View full size image]

Along the top are a series of property pages. The GWIA does quite a bit, so more configuration information might be required. Fortunately, each property page (and most of the dialog boxes that can be spawned from those property pages) have Help buttons. The online help for the GWIA is very informative and should keep you on track if you find yourself editing your GWIA without this book at your side.

Note

Almost all the settings changes you make on the GWIA are held in the GWIA.CFG file, and not in the WPDOMAIN.DB or eDirectory.

Understanding the GroupWise Identification Property Page

The Identification page is most likely over to the right, and it's labeled GroupWise. This section starts here because this is the most basic information on the GWIA.

This page, shown in Figure 10.4, is where general information about the GWIA is configurable. These fields are common to all GroupWise gateways, which is why some of them might seem a little out of place for the GWIA:

  • Domain.Gateway: This is the GroupWise name of the gateway. In the example in Figure 10.4, the value GWIADOM.WWWGWIA means that the agent belongs to the GWIADOM domain and is named WWWGWIA.

  • Description: This is free text; you can use this for the pager number of the GWIA administrator, or perhaps to warn viewers not to change the GWIA object without permission from the administrator.

  • Subdirectory: This field is populated by a drop-down list. It shows where the queue directories for this gateway reside. In the case of the GWIA, you should pick GWIA (or whatever you named your GWIA subdirectory during installation). This is a subdirectory under the DOMAIN\WPGATE directory.

  • Time Zone: By default, the GWIA has the same time zone as its parent domain. This setting is used to timestamp inbound and outbound SMTP/MIME messages.

  • Database Version: For the GroupWise 7 GWIA, this should be set to 7.

  • Platform: In the example for this chapter, the NLM version of the GWIA was installed, so NetWare Loadable Module is selected.

  • Gateway Type: For the GWIA, the only valid value here is Internet Agent. Obviously, with other gateways, other values would be appropriate.

  • Gateway Alias Type: This field is used to associate this GWIA with user or post office aliases. If you have more than one GWIA, you will need to have more than one gateway alias type, because each GWIA (and each GroupWise gateway) must have its own unique gateway alias type.

    Gateway aliases can be useful and sometimes very common, particularly for customers who have used GroupWise for a long time. However, there might be some more effective strategies for giving a person an Internet address than using aliasesfor example, by using a free-form Internet address for the user, and then defining nicknames to the user to allow for multiple incoming Internet addresses for one user. See Chapter 16 for more details.

  • Foreign ID: This is the name by which your GroupWise system will be known on the Internet. It is critical that this value match the domain portion of the To line for all messages that are destined to your users. If the GWIA receives a message that is addressed to a domain that does not match one of its foreign domains, the message will be rejected.

    The Foreign ID field can have several domains on it. The names simply need to be separated by spaces. For example:

    wwwidgets.com worldwidewidgets.com

    The default Internet domain name should be listed first. All others should be listed afterward.

Tip

The Foreign ID field can hold only 124 characters. To accommodate more domain names, the GWIA is hard-coded to look in the DOMAIN\WPGATE\GWIA directory for a file called FRGNAMES.CFG. This is an ASCII text file that contains a listing of all the Internet domain names. Each name should be on a line by itself, and the last line of the file should be blank. Here's an example:

wwwidgets.com
worldwidewidgets.com
sales.worldwidewidgets.com
newyork.worldwidewidgets.com
widgetsoftheworld.com

Note

You can also define which Internet domains the GWIA will receive Internet mail as by using Internet addressing. Chapter 16 discusses Internet addressing; you can use IDOMAINs in the place of multiple domain names on the Foreign ID field or in the FRGNAMES.CFG file. Each Internet domain name you define should have a corresponding MX record in your DNS. We certainly prefer to use this option instead of the option of adding all Internet domains to the Foreign ID field or creating the separate FRGNAMES.CFG file, because this way you can also connect specific Internet domains to domains, post offices, or users, as is also described in Chapter 16.

  • SNMP Community "Get" String: Enter the SNMP community string that the gateway should use for all SNMP GET commands. The community name is case-sensitive.

Configuring the Network Address Property Page

Figure 10.5 shows an example of the Network Address property page.

Figure 10.5. The GWIA Network Address property page allows you to configure the network address

[View full size image]

The most notable fields on this page are as listed here:

  • TCP/IP Address: Enter the TCP/IP address of the server where the GWIA executes.

    By default, the GWIA uses the standardized ports for SMTP, POP3, IMAP4, and LDAP services. For example, SMTP uses port 25, POP3 services uses port 110, IMAP services use 143, and so on. These ports are configurable with the GroupWise 7 GWIA in place.

  • Bind Exclusively to TCP/IP Address: This instructs the GWIA to bind to only the TCP/IP address specified in the TCP/IP Address field. If this field is not checked, the GWIA will bind to all TCP/IP addresses on the server where the GWIA is running.

  • HTTP Port: Enter the HTTP port that the GWIA should use to listen for HTTP monitoring of the GWIA. You should also have an HTTP username and an HTTP password assigned in order to secure the use of HTTP monitoring on the GroupWise GWIA. You can configure these from the Optional Gateway Settings property page on the GroupWise tab.

    The SSL portions of this screen are not discussed in this chapter. Chapter 27, "Securing Your GroupWise System via SSL," gives detailed information on how to enable SSL on the GWIA.

  • Message Transfer: Enter the port that the GWIA should use to listen for messages coming to the GWIA from within the GroupWise system. This feature is new to the GWIA as of GroupWise 7. With this feature, the GWIA no longer receives messages via a queue on the disk; it waits for messages to come into it via communication on the Message Transfer port.

Tip

Do not fill in the IPX/SPX Address field; it's of no use.

The TCP/IP address and HTTP port on any agent are used not only by the agent itself, but also by the GroupWise Monitor Agent. The GroupWise Monitor Agent reads this information in order to monitor the GWIA.

Configuring the GroupWise Gateway Time Settings Property Page

The Gateway Time Settings property page, shown in Figure 10.6, is used to configure the polling intervals and operational cycles for the GWIA. This page is available on the drop-down list of the GroupWise page.

Figure 10.6. The GWIA Gateway Time Settings property page enables you to configure the GWIA's polling intervals and operational cycles

[View full size image]

These are the fields on this page:

  • Send/Receive Cycle: This sets the number of seconds that will be split between the GWIA's send and receive cycles. In the example in Figure 10.6, the 120 seconds specified will give the send and receive cycles each 60 seconds to complete processing. If a message file is being processed when the time expires for that process, the process will complete before swapping out.

  • Minimum Run: This sets the minimum amount of time, in seconds, that the gateway will be "awake" after the idle sleep duration has passed. Typically, this is best set at 0, but if you pay more to open a connection to your ISP than to maintain the connection, you might choose to raise this value. This might catch some additional messages and send them on the current connection, rather than opening a new one for them later.

    Tip

    A minimum run of more than XX seconds is probably going to be meaningful only in conjunction with dial-up connectivity.

  • Idle Sleep Duration: This sets the amount of time, in seconds, that the GWIA will "sleep." During this time, messages can be accumulating in the DOMAIN\WPGATE\GWIA\WPCSOUT\GWIA-FID\0-7 directories. This setting allows you to reduce the amount of CPU time spent supporting polling.

Note

The GWIA is actually three separate processes in one: the MTP receiver, the gateway, and the daemon. The MTP receiver receives messages from the MTA and queues them up to the gateway. The gateway translates messages from GroupWise format to ASCII and vice versa. The daemon listens on port 25 to receive messages and sends the ASCII files generated for it by the gateway as SMTP messages on the Internet. Although the gateway has an idle sleep duration, the daemon never sleeps.

  • Snap Shot Interval: This is a sliding window for statistical purposes. The default, 600 seconds, results in 10 minutes of GWIA statistics being shown on the GWIA console. Regardless of the size of this window, it slides forward every 60 seconds.

For most customers, the default gateway time settings are sufficient.

Configuring the GroupWise Log Settings Property Page

The GroupWise Log Settings Property page looks just like the Log Settings pages for the POA and MTA. The fields on this page are as listed here:

  • Log File Path: By default, this field is blank. GWIA logs are placed in the DOMAIN\WPGATE\GWIA\000.PRC directory. If you choose to keep logs elsewhere, enter the path here. It's not recommended that you configure the GWIA to put logs on a separate server. Performance will suffer, and if the server containing the logs goes down, the GWIA will not function.

  • Logging Level: There are four menu items in this drop-down list:

    • Off: No logging.

    • Normal: The GWIA will track "major" events in the log, but most of the detail will be gone.

    • Verbose: The log will contain useful detail. Although this is not the default, it is the recommended logging level.

    • Diagnostic: This is typically used when troubleshooting the GWIA. It's very detailed and should be run only for troubleshooting purposes.

  • Max Log File Age: This sets the oldest that any log file on disk can be before being automatically deleted by the GWIA. The default is seven days, and this is typically sufficient.

  • Max Log Disk Space: This sets the maximum amount of disk space that the log files can consume. If the logs reach this limit, the oldest log file is deleted. If you choose to set the maximum log file age beyond seven days, you will want to raise this limit as well to ensure that you actually get to keep your oldest logs for the time you specify.

Logging is your friend on the GWIA, particularly if you enable real-time blacklists, as explained later, in the section "Configuring the GWIA Access Control Property Pages."

Configuring the GroupWise Optional Gateway Settings Property Page

Figure 10.7 shows the Optional Gateway Settings page. This page is the same for all GroupWise gateways; there are options here that do not apply to the GWIA. The Directory Sync/Exchange field, for instance, is not supported by the GWIA.

Figure 10.7. The GWIA Optional Gateway Settings property page

[View full size image]

The other fields on this page are as covered here:

  • Accounting: If this field is set to Yes, the GWIA creates an accounting file, ACCT, in the 000.PRC directory, which describes all traffic it processes. This file is emailed each day to the user specified as the Accountant under the Gateway Administrators property page.

  • Convert Status to Messages: This setting does not apply to the GWIA.

  • Outbound Status Level: Set this to Undeliverable so that users get a message if they send mail to an invalid address. You can customize the status messages that users get by configuring the STATUS xx.XML file in the GWIA's root directory under the DOMAIN\WPGATE directory.

  • Enable Recovery: This setting allows the GWIA to restart itself or attempt to reconnect to a foreign host if a connection is interrupted.

  • Retry Count: The GWIA does not read this value; it has hard-coded values it complies with for retries.

  • Retry Interval: The GWIA does not read this value; it has hard-coded values it complies with for retries.

  • Failed Recovery Wait: The GWIA does not read this value; it has hard-coded values it complies with for retries.

  • Network Reattach Command: Populate this field with a command line or with the filename of a batch file for mapping drives to reattach the GWIA to a domain file server. It applies only to the GWIA running on a Windows server. If the GWIA is running on a NetWare server, use the Reattach Settings property page. The Linux GWIA does not use the Network Reattach Command either.

  • Correlation Enabled: Set this to Yes. Correlation is needed for the GWIA to send back undeliverable messages if needed.

  • Correlation Age: Keep the default of 14 days.

  • HTTP Settings: This area has two options:

    • HTTP User Name: Enter the username you will use to monitor the GWIA through a Web browser.

    • HTTP Password: Enter the password you will use when monitoring the GWIA.

Tip

The HTTP information on any GroupWise agent is used not only by the agent itself but also by the GroupWise Monitor Agent. The Monitor Agent reads this information in order to monitor the particular agent.

Your GWIA will work just fine if you do not configure this screen, but we recommend that you do fine-tune the settings mentioned in this section.

Configuring the GroupWise Gateway Administrators Property Page

To make your GWIA RFC-compliant with established SMTP protocols, you must specify a postmaster for the GWIA. From the GroupWise Gateway Administrators property page, you can specify the postmaster of your GroupWise system.

Here is an explanation of the various administrator roles:

  • Operator: Administrators specified as operators will receive certain kinds of GWIA errors in their mailboxes.

  • Accountant: Administrators with this role will receive gateway accounting and statistical logs each day.

  • Postmaster: Administrators with this role will receive any message that comes in to the GWIA addressed to postmaster@GWIA Foreign ID, for example, postmaster@wwwidgets.com.

  • Foreign Operator: This role has no GWIA-related functionality. With other gateways, it allows you to specify a user on a foreign mail system who can email certain commands to the gateway. This field is very useful for gateways that provide direct connectivity between GroupWise and third-party mail systems.

Defining a postmaster is good Internet protocol. Defining an operator is also a good practice.

GroupWise Gateway Aliases Property Page

The Gateway Aliases property page, shown in Figure 10.8, provides a listing of the users who have a gateway alias associated with this GWIA. This is a great feature for determining which user has which gateway alias.

Figure 10.8. The GWIA Gateway Aliases property page

[View full size image]

There is nothing to configure on this property page; it's strictly an informational page. Chapter 16 talks more about using gateway aliases for the GWIA. Consult Chapter 16 before using aliases widely, because most customers will want to avoid gateway aliases for reasons explained there.

SSL Settings Property Page

The SSL Settings page is where you set up the PKI components for SSL encryption. Utilizing SSL is explained fully in Chapter 27.

Configuring the SMTP/MIME Settings Property Page

A whole lot of configuration control is offered through the SMTP/MIME Settings property pages. This is where you govern address handling, message formatting, SMTP dial-up, and other assorted SMTP/MIME-related communications settings. First we will look at the SMTP/MIME Settings property page, as shown in Figure 10.9.

Figure 10.9. The GWIA SMTP/MIME Settings property page

[View full size image]

This page has nine fields that govern some global settings:

  • Enable SMTP Service: This box must be checked before users can send or receive Internet email messages through this GWIA. If you unchecked this box, the GWIA would no longer listen for SMTP sessions on TCP port 25.

  • Number of SMTP Send Threads: This sets the number of server processes, or threads, that will be devoted to SMTP send operations. This setting affects the GWIA's daemon process. If the GWIA runs out of threads (that is, all of them are busy), messages waiting to be sent to Internet recipients will have to wait until a thread is freed up. Most of our customers have this value set to 100.

  • Number of SMTP Receive Threads: sets is the number of server processes that will be devoted to SMTP receive operations. When a sendmail host on the Internet tries to communicate with the GWIA, one receive thread will be dedicated to managing that communication. If no threads are available, the sendmail host will determine that the GWIA is busy or not responding and will retry the transmission according to its own configured preferences. Most of our customers have this value set to 100.

    Because receiving messages is considered to be a higher priority than sending messages, the GWIA will "steal" threads from the Send Threads option, rather than rejecting connections just because it does not have enough receive threads.

  • Hostname/DNS "A Record" Name: This is the name of the GWIA, as it is known on the Internet. Populate this field with a valid DNS name only. This is the name that will be returned to any SMTP service that connects into port 25 on the GWIA. If this name does not match a valid DNS name, you might have problems receiving mail if other SMTP sendmail hosts do reverse-DNS lookups on your GWIA's IP address.

  • Relay Host for Outbound Messages: Some administrators can expose only a very few machines to the Internet through their firewalls. In cases like this, you can configure the GWIA to relay all outbound SMTP/MIME messages through another machine. Populate this field with the IP address or DNS name of the relay host (for example, unixmailer.wwwidgets.com).

  • Scan Cycle for Send Directory: This sets the interval, in seconds, at which the SMTP send threads will poll the SMTP send directory for messages to be transmitted to Internet hosts.

  • Bind to TCP/IP Address at Connection Time: The TCP/IP address noted here is the one on the Network Address property page discussed earlier in this chapter. If a server has multiple IP addresses, the GWIA will send messages using the address defined in the Network Address field. When hosts on the Internet do a reverse-DNS lookup, it is important that the GWIA is sending messages using the IP address that matches its publicly defined DNS A record.

    The GWIA listens for inbound messages on all IP addresses.

  • Use 7 Bit Encoding for All Outbound Messages: When the GWIA sends messages, by default it uses an encoding format called 8-bit MIME. Many older hosts on the Internet cannot understand 8-bit MIME. The GWIA should be able to determine this, and the GWIA will automatically change to sending the message in 7-bit MIME format. If your GWIA is not doing this well, recipients of messages from your GWIA might complain of garbled messages from your GWIA. If this is the case, checking this option will generally resolve this problem.

  • Maximum Number of Hours to Retry a Deferred Message: When the GWIA gets a 4XX-level SMTP error, this setting determines how long the GWIA will retry sending the message before giving up, and sending an undeliverable status message to the original recipient. The default is 96 hours. If you set the maximum to 0, senders will immediately get a message from the GWIA reporting that the GWIA cannot send to the Internet host, if the GWIA has a 4XX-type error.

    Using the option Intervals to Retry a Deferred Message, GWIA can be configured on how it manages retries. So if you were to use the factory default settings of 20,40,60,240 minutes, here is what would happen. Imagine that the GWIA tries to send to another Internet mailer on the Internet. But the GWIA reports a 450 Host Down error in its log file. The GWIA will move the message to the DOMAIN\WPGATE\GWIA\DEFER directory and then requeue the message to the DAEMON process on the GWIA after 20 minutes has passed. If the message fails, the GWIA will wait another 40 minutes and try again. If after another 40 minutes the GWIA cannot send the message, it will try to send the message again in 60 minutes. If after another 60 minutes the GWIA cannot send the message, it will retry after 240 minutes (four hours), and then try again after another four hours, until it has tried for 96 hours (four days). The only piece of this algorithm you can change is for how long the GWIA will continue retrying.

    If you set Maximum Number of Hours to Retry a Deferred Message to 0, senders will immediately get a message back from the GWIA reporting that the GWIA cannot send to the Internet host, if the GWIA has a 4XX-type error. For example, if the GWIA reports a 450 Host Down error, the GWIA will send a message to the sender indicating that the Internet host is down.

    The default settings for the GWIA might not be the best for your environment. Perhaps you will want to increase threads, or you might not want the GWIA to retry a message for four days.

  • Do Not Publish GroupWise Information on an Initial SMTP Connection: If there is a check mark on this choice, the GWIA will not announce that it is a GroupWise Internet gateway as it usually does. This feature was added for security reasons.

Configuring the SMTP/MIME Address Handling Property Page

The Address Handling property page (see Figure 10.10) is generally a place where you make settings, and then leave them as they are.

Figure 10.10. The SMTP/MIME Address Handling property page

[View full size image]

The settings on this page are as listed here:

  • Addressing Style: The Ignore GroupWise Internet Addressing setting allows the administrator to revert to old-style GroupWise address parsing at the GWIA level only. When you use this option, all replies to Internet mail must go back out the same GWIA they came in. Also, if you use this option, the GWIA will receive mail only to domains defined in the Foreign ID field. It will not read the IDOMAIN list of domain names from the domain database. Also, the GWIA will not try to resolve recipient addresses to the newer formats Internet addressing provides, such as First.Last, Last.First, and the free-form Internet address you can define on the GroupWise user ID. Leave this box unchecked unless you have been told to check it by Novell technical support. By default, this setting is unchecked.

Note

Checking the Ignore GroupWise Internet Addressing option enables the /DIA switch in the GWIA.CFG file. For a complete discussion of Internet addressing, refer to Chapter 16.

  • Inbound Settings: The Expand Distribution Lists on Incoming Messages check box allows for some very powerful functionality. If Expand Distribution Lists on Incoming Messages is checked, Internet users can send to distribution lists on your GroupWise system. They will need to know the name of the list, and would simply address their message to groupname@host. For example, to send to the CorpUsers distribution list on our sample system, an Internet email user would address the message to corpusers@wwwidgets.com. The GWIA would then expand the address of the message, adding each of the mailboxes listed under the CorpUsers distribution list.

  • Outbound Settings: The address format settings under the Outbound Settings options become obsolete when GroupWise Internet addressing is enabled. For more information on Internet addressing, see Chapter 16. These are the settings you can choose from here:

    • Non-GroupWise Domain for RFC-822 Replies: This field builds the TO line when a GroupWise user replies to an RFC-822 (SMTP) message that came in through the GWIA.

    • Non-GroupWise Domain for MIME Replies: This field builds the TO line when a GroupWise user replies to a MIME message that came in through the GWIA.

    • Sender's Address Format: This setting is enabled only if Ignore GroupWise Internet Addressing has been checked. It allows you to choose how the GroupWise user's reply-to address is built from the various components of his or her GroupWise address.

    • Place Domain and Post Office Qualifiers: These radio buttons allow you to choose where domain and post office components go if they are included in the Sender's Address Format field you selected. If they are on the left, the address is user.po.domain@host. If they are on the right, the address reads as user@po.domain.host.

    • Expand Distribution Lists on Outgoing Messages: With this choice enabled, when a message is sent to a distribution list, and Internet recipients, all the recipients in the distribution list will be listed in the email. The potential downside to this feature is that the header portion of the SMTP message can be large if the distribution list is also large.

    • Retain Distribution Lists: With this feature enabled, if a message is sent to a distribution list, and to users on the Internet, the distribution list name is listed in the address line, and not all the individual recipients of the message. This switch corresponds to /keepsendgroups in the GWIA.CFG file.

    • Use GroupWise User Address as Mail From: With the For Rule Generated Messages feature enabled, if a message is generated by a rule (if you allow for rule-generated email through the GWIA), then the message will indicate the From address as the actual sender, rather than the postmaster or the GWIA daemon. Warning: You should enable this feature only if you are positive that you should. You could cause rule loops if the recipient across the Internet is using rules also. The corresponding switch in the GWIA.CFG is /realmailfrom.

You should consult Chapter 16 before making changes on most of the settings on this page.

Configuring the SMTP/MIME Dial-Up Settings Property Page

Later in this chapter, there's a section called "Configuring Dial-Up Internet Access" that talks about how to use the Dial-Up Settings page.

Configuring the SMTP/MIME ESMTP Settings Property Page

ESMTP stands for extended SMTP. The ESMTP protocol is a special protocol through which enhancements to the SMTP protocol, called service extensions, can be created. The GWIA supports ESMTP service extensions. Some of the ESMTP extensions that the GWIA supports are the following:

  • DSN

  • STARTTLS (secure SMTP, POP, or IMAP over TLS/SSL)

  • AUTH

DSN

DSN is short for Delivery Status Notification. This protocol is described in the Internet RFC 1894. By enabling this protocol, the GWIA can confirm to the sender that the sender's message was delivered to the intended recipient. Before the DSN protocol, the GWIA would report only problems getting a message to its recipient's host. The sender had to assume that the recipient got the message, because the sender never got a response back saying that it was or wasn't received.

With the DSN Hold Age option, you select the number of days that you want the Internet Agent to retain information about the external sender so that status updates can be delivered to the sender. The default hold age of four days causes the sender information to be retained for four days. If the Internet Agent does not receive delivery status notification from the receiving SMTP server within that time period, it deletes the sender information and the sender does not receive any delivery status notification.

Note

A DSN Hold Age of four days is plenty generous. Generally, you will not want to increase the DSN Hold Age over four days. The Delivery Status Notification pointer messages are kept in the ...\WPGATE\GWIA\DSNHOLD directory. If you ever go out to this directory and see a bunch of files, don't let this alarm you. You should not see files older than the DSN Hold Age you specified. If you do, you can delete those files.

STARTTLS

The GWIA supports sending messages over the Internet via SSL. This is a rather new protocol, and the GWIA will send SSL encrypted messages only to SMTP hosts that will receive via the STARTTLS protocol. The STARTTLS protocol is described in RFC 2487. Chapter 27 talks about how to enable STARTTLS on the GWIA.

AUTH

When this feature is enabled, the GWIA can allow other SMTP gateways to authenticate before sending mail. This is useful if you have relaying disabled. Anyone that authenticates is allowed to relay off the GWIA. At the end of this chapter there is discussion of the GWAUTH.CFG, which is what enables support for the AUTH functionality of the GWIA.

Configuring the SMTP/MIME Message Formatting Property Page

From the Message Formatting page, you set the inbound and outbound settings for conversion of messages to and from GroupWise format. The Inbound Settings portion has two available fields for you to edit:

  • Number of Inbound Conversion Threads: This sets the maximum number of server processes the GWIA will devote to converting messages from SMTP/MIME format to GroupWise format. This setting affects the GWIA's gateway process, and not its daemon process.

  • GroupWise View Name for Incoming Messages: This sets the name of the view (the embedded name, not the actual filename) that the GroupWise client will be told to use when displaying a message that was received from the Internet. This field should not be edited unless you are designing your own views with the GroupWise SDK. GroupWise views are the *.VEW files in a post office OFVIEWS\WIN directory. Use this feature if you want all inbound Internet mail to be displayed using a custom view file from the GroupWise client. You can add a note to the view that says this file was received from the Internet as an SMTP message or something to this effect, if you want.

Tip

If you change the name of the view from Internet to something else, users cannot use the anti-spam capabilities in the GroupWise client. This is because the GroupWise client identifies mail that came from the Internet by looking for the view type of Internet.

Under Outbound Settings, you have a few more fields to focus on. These settings are more likely to have an effect on your users' Internet email experience:

  • Number of Outbound Conversion Threads: This sets the maximum number of server processes the GWIA will devote to converting messages from GroupWise format to SMTP/MIME format. This setting affects the GWIA's gateway process, and not its daemon process.

  • Default Message Encoding: There are two options here. Basic RFC-822 is the older message format. MIME is the newer standard, and it is generally more efficient when binary files (executables, images, and so on) need to be transmitted. When RFC-822 encoding is selected, binary attachments must be encoded in the 7-bit uuencode format. The UUEncode All Text Attachments option will force text attachments to also be encoded.

Note

If your users complain that people that they send Internet email to cannot read the messages they send, you might investigate whether enabling RFC-822 encoding on all messages resolves this issue.

  • Enable Quoted Printable Text Line Wrapping: This check box allows you to select the quoted printable MIME standard for text line wrapping. If this is not checked, outbound messages will wrap text according to the Line Wrap Length setting that follows this one.

  • Line Wrap Length for Message Text on Outbound Mail: This sets the number of characters after which the GWIA inserts a soft return. This prevents messages entered with no returns from appearing all on the same line. Of course, the recipient's mailer might need to be "told" to respect the soft-return character.

  • Enable Flat Forward: This check box tells the GWIA to strip out empty messages in which there is no message body, but just an attached message. So, for example, if USERA forwards a message to USERB, without composing a message body, the message body USERB sees will be the forwarded message. This feature is especially helpful to people who receive messages to devices such as pagers. In previous versions we needed to use the corresponding switch in the GWIA.CFG called /flatfwd.

  • Disable Mapping X-Priority Fields: This check box tells the GWIA not to map X-Spam flags to emails so that the messages go to a user's Junk Mail folder. This feature and Junk Mail are discussed more in Chapter 25, "Configuring a Spam/Junk Mail Control Solution."

Configuring the SMTP/MIME Junk Mail Property Page

Chapter 25 talks about how to incorporate the features of the Junk Mail property page into your overall Spam/Junk Mail control scheme.

Configuring the SMTP/MIME Scheduling Property Page

The GWIA SMTP/MIME Scheduling property page is used to define the times of the day and days of the week that the GWIA will process SMTP/MIME messages. Scheduling cannot be employed for POP3, IMAP4, or LDAP services. If those services are enabled, the GWIA will attempt to provide them all the time, regardless of the settings made on the Scheduling property page.

The Scheduling property page is especially useful when configuring the GWIA for dial-up access to the Internet, using the SMTP/MIME Dial-up Settings property page.

Configuring the SMTP/MIME Security Settings Property Page

Security is an important part of any Internet strategy. Because the GWIA is normally exposed to the Internet when receiving messages, it is critical that it be protected against certain kinds of attacks. The SMTP Security Settings dialog box in Figure 10.11 allows you to defend the GWIA from two kinds of common email attacks: identity spoofing and mailbombs.

Figure 10.11. The GWIA SMTP/MIME Security Settings property page allows you to protect against spam and mailbombs

[View full size image]

The settings on this page are as listed here:

  • Reject Mail If Sender's Identity Cannot Be Verified: This setting prevents the GWIA from accepting email from anonymous sendmail hosts. Although some legitimate email is routed in this manner, spammers often use anonymous mailers. The GWIA will perform a reverse-DNS lookup on the name of the sendmail host to verify that its given name is in the DNS tables on the Internet. If it cannot find the name, it will not accept mail from this host.

    Although it might seem logical to enable Reject Mail If Sender's Identity Cannot Be Verified, enabling this feature might cause your system to reject email from legitimate hosts. The reason for this is that the site sending to your GWIA might not have defined the A record of its SMTP mailing host. This problem is evidence of a lack of correct DNS configuration, but alas, the world isn't perfect.

  • Enable Mailbomb Protection: If this option is checked, the GWIA will use the mailbomb thresholds to prevent a single host from tying up the GWIA inbound threads with a mass mailing. Some mass mailings are actually designed not to deliver large numbers of messages, but to tie up the receiving host. The default mailbomb threshold of 30 messages received in 10 seconds is typically sufficient to identify a mailbomb attack before any harm is done.

If you need to enable a spam solution for the GWIA, be sure to see Chapter 25.

Configuring the SMTP/MIME Timeouts Property Page

Each of the fields on the Timeouts property page is populated with the number of minutes (not seconds) that the GWIA will wait before timing out on a particular operation. This timeout can be due to a noisy line, an unresponsive host, or some other loss of connectivity.

Configuring the SMTP/MIME Undeliverables Property Page

The Undeliverables property page is where you instruct the GWIA how to handle inbound messages that cannot be delivered.

Note

The destination mail host handles undeliverable messages that are outbound. That host can choose to reply, forward the message to the configured postmaster, or simply discard the message. As a GroupWise administrator, you have no control over how other email administrators choose to handle undeliverable email.

Be aware that these options were used with older versions of GroupWise but do not work anymore with version 6.x or higher.

These are the settings on this page:

  • Amount of Original Message to Return to Sender When Message Is Undeliverable: This sets the amount of the original message, in kilobytes, that will be returned to the sender if the message cannot be delivered. Typically, it is not necessary for a sender to have more than a few lines of his or her message to identify it. This allows you to save a little bit of bandwidth.

  • Forward Undeliverable Inbound Messages to Host: If you are operating a heterogeneous mail system, you might have a single DNS name but multiple mail hosts. If the GWIA is the default inbound mail host, you can configure it to forward any undeliverable messages to another mail host on your system. This other mail host might then find the desired recipient of the email message. This option is useful when you are using Novell's NetMail mail system with the same domain name as your GroupWise users.

  • Move to Problem Directory: If this option is checked, undeliverable messages are placed in the GWPROB directory of the GWIA subdirectory.

Note

The GWPROB directory is not purged automatically. You will have to purge it manually on occasion.

  • Send to Postmaster: If this option is checked, the user who has been configured as the postmaster will receive the full text (and attachments) of any undeliverable messages. This allows the postmaster to straighten out addressing problems, as well as to manually forward messages to the correct recipients.

    If neither of the previous two options is checked, problematic messages are simply discarded.

It is important that you create an undeliverable mail strategy, and configure it using the settings on the SMTP/MIME Undeliverables property page.

Configuring the SMTP/MIME Junk Mail Property Page

The Junk Mail property page is really just an editor for the xspam.cfg file. Following is a short explanation of the Junk Mail feature.

You can use the Flag Any Messages That Contain x-spam-flag option to flag messages for handling by the client Junk Mail Handling feature if they contain x-spamflag=yes in the MIME header. This will create the xspam.cfg file in the domain\wpgate\gwia directory. Each line of the xspam.cfg file identifies an "X" header field that your anti-spam service is writing to the MIME header, along with the values that flag the message as spam. The Internet Agent examines the MIME header for any field listed in the xspam.cfg file. When a match occurs, the message is marked for handling by the GroupWise client Junk Mail Handling feature. More information can be found in Chapter 25.

Configuring the LDAP Settings Property Page

The LDAP Settings property page, shown in Figure 10.12, allows you to configure the LDAP service provided by the GWIA. To complete configuration of the LDAP service, however, you must also choose Allow Access from the LDAP Public Settings property page, which is on the Access Control tab. From the LDAP Public Settings page, you can also limit which fields on a user's address information are visible to a client's LDAP address lookup query against your GWIA.

Figure 10.12. The GWIA LDAP Settings property page

[View full size image]

The settings that you can configure on this page are as listed here:

  • Enable LDAP Service: This must be checked for the GWIA to be able to provide LDAP service to browsers and email clients.

  • Number of LDAP Threads: This sets the maximum number of server processes that will be devoted to handling LDAP requests.

  • LDAP Context: Set a Search Root, which for the GroupWise LDAP directory doesn't really do anything. This setting is required for LDAP clients to be able to speak in LDAP to the GWIA; for example, o=wwwidgets.

    For users, the Search Root entry in your users' browsers' or email clients' LDAP setup information must match the string you have in the LDAP Context field. (Search Root is the term used by Netscape Communicator. Search Base is the term used by MS Outlook Express.)

  • LDAP Referral URL: This setting allows you to define a secondary LDAP server to which you can refer queries that the GWIA was unable to resolve. Obviously, the secondary LDAP server would be configured and managed separately from the GWIA. For this feature to work, the client performing the LDAP lookup to the GWIA must support the tracking of referral URLs.

The LDAP feature of the GWIA isn't very robust, so you might want to consider a different LDAP directory solution, such as eDirectory.

Configuring the POP3/IMAP4 Settings Property Page

If you want your users to be able to use a POP3 or IMAP4 email client to access their GroupWise messages, you will need to begin by enabling POP3 and IMAP4. To complete configuration of the POP3 and IMAP4 service, however, you must allow POP3 and/or IMAP4 access from the Access Control property page, described a little later in this chapter. From this page, you can configure the following:

  • Enable POP3 Service: This option must be checked before the GWIA will respond to POP3 requests from email clients.

  • Number of Threads for POP3 Connections: This sets the maximum number of server processes that the GWIA will devote to servicing POP3 mailbox connections. Each connection will tie up one thread, but connections are usually cleared fairly quickly. A small number of threads can support a large user community, depending on how often users download email via POP3.

  • Number of Threads for POP3 SSL Connections: This sets the maximum number of server processes that the GWIA will devote to servicing secure POP3 mailbox connections. Each connection will tie up one thread, but connections are usually cleared fairly quickly. A small number of threads can support a large user community, depending on how often users download email via POP3.

  • Enable Intruder Detection: This new GroupWise 7 feature allows the GWIA to piggyback the intruder detection engine if it is enabled at a GroupWise post office. Intruder detection is enabled under the Client Access Settings of a GroupWise post office object. This setting corresponds to the GWIA.CFG switch /popintruderdetect.

  • Enable IMAP4 Service: This must be checked before the GWIA will respond to IMAP4 requests from email clients.

  • Number of Threads for IMAP4 Connections: This sets the maximum number of server processes that the GWIA will devote to servicing IMAP4 mailbox connections. Each connection will take up one thread, and connections are more latent than POP3 connections are. This is due to the fact that with IMAP4, the user mailbox always exists on the server, and the client must rerequest items that the user wants to reread.

  • Number of Threads for IMAP4 SSL Connections: This sets the maximum number of server processes that the GWIA will devote to servicing secure IMAP4 mailbox connections. Each connection will take up one thread, and connections are more latent than POP3 connections are. This is due to the fact that with IMAP4, the user mailbox always exists on the server, and the client must rerequest items that the user wants to reread.

  • Maximum Number of Items to Read (in Thousands): This is yet another method you can employ to reduce the processing tasks on the GWIA. Keeping the setting at 0 means that there is no maximum. The corresponding setting in the GWIA.CFG is /imapreadlimit.

For more information about setting up POP3 or IMAP4 access for your users, refer to the section "Configuring Access Control," later in this chapter.

Configuring the Server Directories Settings Property Page

Some third-party software requires that you configure the Server Directories Settings property page that the GWIA uses to process SMTP/MIME messages. Otherwise, the defaults work fine. The settings you can configure on this page are discussed here:

  • Conversion Directory: This path becomes the GWIA's "work" directory. By default, this is found at domain\WPGATE\GWIA\000.PRC\GWWORK. The GWIA uses this directory to store temporary files used during message conversion.

  • SMTP Queues Directory: This path becomes the parent directory for the SMTP SEND, RECEIVE, and RESULT directories, which are the input and output queues for the SMTP inbound and outbound threads.

  • Advanced: Clicking this button brings up the SMTP Service Queues Directory dialog box. This dialog box is used for trapping messages between the SMTP daemon and the gateway. If you populate this field with a path, all inbound and outbound messages will be dropped in subdirectories of this directory. They will remain there until another process moves them to the appropriate SMTP queue directory. An example of third-party software that will require that you use this field is Guinevere from GWAVA (www.gwava.com). Typically, these directories are located under the domain directory, in the GWIA structure under WPGATE.

Generally, you should keep the default settings on this property page unless you are implementing third-party software.

Configuring the GWIA Access Control Property Pages

The GWIA Access Control property pages are used to configure blacklists (spam blocking) POP3, LDAP, IMAP4, and SMTP relay access for the GWIA. These property pages (except the Blacklist feature) allow for the creation of classes of service and memberships. Each membership can be assigned to one or more classes of service.

This property page is explained and utilized in the section "Configuring Access Control," later in this chapter.

Using the Access Control Test Property Page

The GWIA Access Control Test property page allows you to test the memberships and classes of service created with the Access Control property page. The display can be changed to include domains, post offices, distribution lists, or users.

Clicking View Access displays a dialog box that shows the GWIA access allowed for the selected object. The Access Control Test property page is used in an example later in this chapter.

Using the Access Control Blacklists Property Page

Chapter 25 talks about how to configure the Blacklist (RBL) feature of the GWIA. Read this chapter for instructions on how to configure the settings on this page.

Using the Access Control SMTP Relay Settings Property Page

The Relay Settings page allows you to define whether your GWIA is an open relay. It also lets you define exceptions to allow specific hosts to relay or not relay off your GWIA. You can also use the Access Control settings to define relay exceptions. An example of this is given later in this chapter.

Using the Access Control LDAP Public Settings Property Page

See the section "Configuring the LDAP Settings Property Page" earlier in this chapter for how you should use the Public Settings page.

Using the Access Control Database Management Property Page

The GWIA does not use the domain database for access control. The access control database is called GWAC.DB, and it's in the DOMAIN\WPGATE\GWIA directory. Thus, a separate tool has been provided for maintaining and repairing the GWIA access control database. You can configure the following options from this page:

  • Validate Now: This button checks the physical structure of the database, essentially making sure that all records can be read correctly. Clicking Validate Now displays a live validation window that shows the validation process's progress.

  • Recover Now: The recover option should be used only after the validation report has been generated and reviewed. Recovery is not a perfect process. If records have been damaged and cannot be read, they cannot be regenerated. They will be removed, and the new, recovered access database will not re-create the removed records.

    Any addresses you define in the blacklist section of the GWIA are not written to the GWAC.DB file. These setting are contained in BLOCKED.TXT.

The Access Control features of the GWIA make the GWIA very flexible. Be sure to utilize these features of the GWIA to control the maximum message size that users can send on the Internet, or the maximum size of Internet messages your GWIA will receive.

Understanding the Reattach Settings Property Page

First off, this page applies only to the GWIA when it runs on the NetWare platform. When the GroupWise GWIA acts as a POP3 or IMAP4 server, it must access the POP3/IMAP4 user's mailbox. In the Post Office Links property page, the links to post offices can be UNC or TCP/IP. The TCP/IP link is generally preferred, but if UNC is chosen, the GWIA must log in to the server using a user ID and password in the fields in this property page.

The settings on this page are as listed here:

  • Tree: This is the name of the eDirectory tree that the GWIA is logging in to.

  • Context: This is the eDirectory context for the user the GWIA will attempt to connect as.

  • User ID: This is the eDirectory user object that the GWIA will attempt to connect as.

  • Password: This is the password that the GWIA will use when logging in.

    We highly recommend that if you do enable POP3/IMAP4 on the GWIA, you allow the GWIA to connect to post offices only via TCP/IP connection, not via a UNC path connection.

Most customers will not have to use the settings on this page.

Using the Post Office Links Property Page

The Post Office Links property page is used to define the connection between the GWIA and each of the post offices to which it must connect to provide users with POP3 or IMAP4 access. As recommended in the preceding text, you should configure your GWIA to talk to your POAs via a TCP/IP client/server link to the POA.

Tip

If you do not intend to enable POP3 or IMAP4 features on your GWIA, don't worry about configuring the link to the post offices.


Configuring Access Control

By default, everyone in your organization has full access to all features you enable on the GWIA. This includes the capability to collect their email via POP3 or IMAP4 service, as well as to send and receive messages of unlimited size via SMTP/MIME.

For many customers, though, the following are common settings under Access Control:

  • There is no POP3 or IMAP4 mailbox access.

  • SMTP relay access is turned off.

  • No rule-generated messages can be sent through the GWIA.

  • Users are limited to a certain message size that they can send through the Internet.

You can administer all of these controls on the GWIA via Access Control. Generally, when you want your Access Control to apply to all users, you configure the Default Class of Service. Imagine, though, that you want to be able to make exceptions to the settings you defined from Default Class of Service. For example, a couple of users will eventually need POP3 access. Here are the steps to accomplish such exceptions:

1.
Open the GWIA object's properties window and go to the Access Control, Settings property page.

2.
To the right of the Class of Service pane, click Create.

You should be presented with the dialog box shown in Figure 10.13.

Figure 10.13. Creating a new class of service

[View full size image]

3.
Enter a name for this class of service, such as POP3 Access.

After clicking OK and selecting the POP3 tab, you get the screen shown in Figure 10.14.

Figure 10.14. The Edit Class of Service dialog box allows you to define how the service is configured

[View full size image]

4.
Beneath the defaults, select Allow Access and leave all other settings at their defaults. Click OK.

5.
You will be presented with a user list, as shown in Figure 10.15. Select the users who can use the GWIA as a POP3 server, and click OK.

Figure 10.15. Adding users to a class of service

[View full size image]

The users defined under the POP3 Access Class of Service will be able to retrieve their email via POP3, and relay off of the GWIA.

It is important to note that you did not configure any type of SMTP relay on the GWIA, yet these POP3 users are able to relay off of the GWIA. The reason for this is that the GWIA will allow a user who has authenticated via a POP3 session to relay through the GWIA. Because the POP3 session required the user to authenticate as a valid user, the GWIA assumes that the user should be able to use the GWIA as an SMTP relay server.

For your users to be able to use SMTP relay, their POP3 client must be configured to allow authentication to the SMTP server (which is the POP3 server also) before sending SMTP messages to be relayed. Some newer POP3 clients just assume that this is the case, so this option of whether to do it is not even presented to the users.

Let's imagine another scenario. You have deployed Novell's ZENworks server management product. The ZENworks server management product has an alerting mechanism that requires an SMTP relay host. You want your GWIA to allow relaying, but only from the server running the ZENworks server management.

Following are the steps for setting up the GWIA to act as a relay host:

1.
In the GWIA's property pages, select Access Control, SMTP Relay Settings. Confirm that the radio button Prevent Message Relaying is selected.

2.
Under Exceptions, and to the right of the Allow pane, click Create.

3.
In the From field, enter the IP addresses that will be allowed to relay through the GWIA. You do not need to specify a To address.

4.
Click OK, and you will see the new exception as shown in Figure 10.16. Click OK again to save all changes.

Figure 10.16. Adding an exception to the SMTP relay access

[View full size image]


Understanding the GWIA

The NetWare-based GWIA console is particularly helpful when troubleshooting the GWIA. Generally, the GWIAs on the Linux and the Windows platform run without a user interface. The best way to monitor this version of the GWIA is with HTTP monitoring, which is explained later in this chapter.

Figure 10.17 shows the GWIA console on a NetWare 6.5 server.

Figure 10.17. The GWIA console allows you to view and troubleshoot the GWIA

[View full size image]

From the GWIA console, there are only five keystroke commands:

  • F6Restart: This feature causes the GWIA to reload, and reread its GWIA.CFG and other special-purpose GWIA configuration files, such as FRGNAMES.CFG, GWAUTH.CFG, MIMETYPE.CFG, ROUTE.CFG, and XSPAM.CFG. The purpose of these *.CFG files is explained later in this chapter.

  • F7Exit: This option presents you with the following prompt: Terminate Agent (Yes/No). Pressing Y unloads the GWIA module.

  • F8Info: This option reports the settings from GWIA.CFG, the GWIA configuration file, into the current log file. This is helpful for determining which settings the GWIA is currently observing.

  • F9Browse Log File: This option allows you to search the current log file that the GWIA is logging to.

  • F10Options: This option brings you into the GWIA Options menu, where you have the following choices:

    • F1Exit Options: This option exits the Options menu, taking you back to the main screen.

    • F2Log Level: This option toggles the log level through the various settings: Low, Normal, Verbose, and Diagnostic.

    • F6Colors: This option changes the color scheme of the GWIA console. None of the color schemes is especially attractive, but if you get tired of the white-on-blue, this at least gives you some options.

    • F8Zero Stats: This option resets to zero all the statistics that the GWIA has been keeping. This is useful if you want to note current traffic levels. This command clears the statistics only from the Message Statistics screen. It does not reset the SMTP, POP, IMAP, or LDAP statistics.

    • F9Stats: This option cycles the upper-right pane of the GWIA console between each of the five statistical panes: Message Statistics, SMTP Service Statistics, POP3 Service Statistics, LDAP Service Statistics, and IMAP4 Service Statistics.

The balance of this section looks at these five statistics a little more closely:

  • Message Statistics: These are general statistics that have to do with mail messages that are converted by the gateway process. Each statistic is reported in two ways: the total time that the GWIA has been loaded and the total messages processed for the preceding 10 minutes. These are the possibilities:

    • Normal: The number of mail messages that the gateway has processed.

    • Status: The number of status messages that the gateway has processed. These are typically transferred statuses sent back to users on this GroupWise system.

    • Passthrough: This feature is no longer valid. Pass-through messaging happens at the MTA level now, and is explained in Chapter 34, "Creating a GroupWise-to-GroupWise Communication Solution Across the Internet."

    • Conv Errors: The number of errors the gateway has encountered while attempting to convert messages from GroupWise format to other formats, and vice versa.

    • Comm Errors: The number of communication errors the gateway has encountered while attempting to communicate with other hosts.

    • Total Bytes: The number of bytes transferred through the GWIA.

  • SMTP Service Statistics: These statistics pertain to the SMTP services provided by the GWIA. Some of these statistics are incorporated into the general message statistics described earlier, but for the real story, you want to be looking at this screen. Values here are the following:

    • Messages Sent: The number of messages sent to sendmail (SMTP or MIME) hosts on the Internet.

    • Send Threads: The number of server processes actively processing SMTP/MIME send operations. The number to the left of the colon is the number of threads currently being used. The number to the right of the colon is the maximum number of threads allocated for sending messages. The maximum number of Send Threads correlates to the Number of SMTP Send Threads setting on the GWIA's SMTP/MIME Settings page.

    • MX Lookup Errs: The number of errors the GWIA has encountered when looking up DNS mail exchange (MX) records. Before the GWIA can send to an Internet host, it must first find that host's MX record in DNS. An example of an MX lookup error is 450 MX lookup failure.

    • TCP/IP Read Errs: The number of errors the GWIA has encountered attempting to read from a TCP socket. Errors here can indicate problems with internetworking segments that carry Internet traffic, or they can be indicative of network problems within your organization.

    • Hosts Down: If the GWIA finds a hosts MX record but cannot contact the host, that host is down, and this number will be incremented by one.

    • Message Size Denied: This number indicates the number of messages, to be sent or to be received, that were discarded because they exceeded size limitations set on your GWIA. Message sizes are configured under Access Control, and most likely configured under any one of the Classes of Server, most likely the Default Class of service.

    • Messages Received: The number of SMTP/MIME messages received by the GWIA from hosts on the Internet.

    • Receive Threads: The number of server processes actively processing SMTP/MIME receive operations. The number to the left of the colon is the number of threads being used. The number to the right of the colon is the maximum number of threads allocated for receiving messages. The maximum number of receive threads correlates to the Number of SMTP Receive Threads setting on the GWIA's SMTP/MIME Settings page.

    • Unknown Hosts: The number of SMTP hosts the GWIA cannot resolve to a DNS address in order to send to the host.

    • TCP/IP Write Errs: The number of errors that the GWIA has encountered attempting to write data to a TCP socket. Errors here can indicate a problem local to you, or a problem somewhere out on the Internet.

    • Connections Denied: When a sendmail host sends to the GWIA, but that host does not identify itself correctly or its identity cannot be determined via a reverse-DNS lookup, this number is incremented. Mail from unknown hosts will be rejected if you configure the GWIA to do so. This setting is found on the SMTP/MIME Settings property page, using the Security button. The setting is Reject Mail If Sender's Identity Cannot Be Verified. Connections that have been denied because the host has been added to a blacklist are also listed here. Finally, if you have defined a host under Access Control that you do not want to receive mail from, that will also increment this number.

    • Relaying Denied: If your GWIA is configured to not allow message relaying, and someone attempts to relay a message off of your GWIA, this number will increment each time. Relaying is a common practice for POP3 and IMAP4 clients that need to send mail.

  • POP3 Service Statistics: These statistics pertain to the GWIA's POP3 service and can help you gauge the amount of traffic your organization is generating by accessing user mailboxes via POP3. These are the values shown here:

    • Total Sessions: The number of POP3 mailbox sessions since the GWIA was loaded. A POP3 session is defined as a download of POP3 mail. If a user keeps his or her POP3 mailer open all day, and downloads GroupWise email three times, that user will increment this count by three.

    • Active Sessions: The number of POP3 currently active mailbox sessions.

    • Sessions Avail: The number of server processes available to service POP3 mailbox connections. The active and avail numbers should add up to the number of POP3 threads you specified under the GWIA POP3/IMAP4 Settings property page.

    • Store Login Errs: The number of errors that the GWIA has encountered attempting to connect to post office information stores. If you see this number incrementing, it's time to look at the GWIA's Post Office Links property page. From there, make sure that the links to your post offices are correct and that the POA is available.

    • Unknown Users: The number of errors in which the username furnished was invalid. A high number here might be indicative of a hacker attempting to guess mailbox IDs.

    • TCP/IP Read Errs: The number of errors that the GWIA has encountered attempting to read data from a TCP socket.

    • Messages Sent: The number of messages downloaded to users' POP3 mailers and uploaded to their master mailboxes.

    • Retrieval Errs: The number of errors encountered retrieving messages from post office information stores.

    • Conversion Errs: The number of errors encountered converting messages from GroupWise format to clear text format for POP3 download.

    • Pass Auth Errors: The number of errors that the GWIA has encountered due to users entering invalid passwords. A high number here can be indicative of a hacker with a correct username attempting to guess at the mailbox password.

    • Denied Access Cnt: The number of times that the GWIA has denied mailbox access to a user attempting to authenticate. A high number here can indicate hackers guessing at mailbox IDs and passwords.

    • TCP/IP Write Errs: The number of errors that the GWIA has encountered attempting to write data to a TCP socket.

  • LDAP Service Statistics: The statistics here pertain to the GWIA's LDAP service, as detailed here:

    • Public Sessions: The number of LDAP sessions that the GWIA has opened for users who were not authenticated.

    • Auth Sessions: The number of LDAP sessions that the GWIA has performed for authenticated users.

    • Sessions Active: The number of LDAP sessions currently active. Each active session requires its own LDAP thread.

    • Sessions Avail: The number of LDAP threads available to service LDAP sessions. The Active and Avail numbers should add up to the number of LDAP threads that you specified from the GWIA's LDAP Settings property page.

    • Search Requests: The number of search requests that the GWIA has processed.

    • Entries Returned: The number of address entries that the GWIA has provided via LDAP.

  • IMAP4 Service Statistics: The statistics here are very similar to those seen under the POP3 Service Statistics screen, but of course these are specific to IMAP4 service. The statistics in this section are as listed here:

    • Total Sessions: The number of IMAP4 mailbox sessions since the GWIA was loaded. If a user keeps his or her IMAP4 mailer open and connected all day, this number will increment only by one. (Remember that these stats are reset to zero with the F8 key; the IMAP4 stats are not reset, however.)

    • Active Sessions: The number of IMAP4 currently active mailbox sessions.

    • Sessions Avail: The number of server processes available to service IMAP4 mailbox connections. The active and avail numbers should add up to the number of IMAP4 threads that you specified on the GWIA POP3/IMAP4 Settings property page.

    • Store Login Errs: The number of errors that the GWIA has encountered attempting to connect to post office information stores. If you see this number incrementing, it's time to look at the GWIA's Post Office Links property page. From there, make sure that the links to your post offices are correct.

    • Unknown Users: The number of errors in which the username furnished was invalid. A high number here can be indicative of a hacker attempting to guess mailbox IDs.

    • TCP/IP Read Errs: The number of errors that the GWIA has encountered attempting to read data from a TCP socket.

    • Messages Sent: The number of messages downloaded to users' IMAP4 mailers and uploaded to their master mailboxes.

    • Retrieval Errs: The number of errors encountered retrieving messages from post office information stores.

    • Conversion Errs: The number of errors encountered converting messages from GroupWise format to clear text format for IMAP4 download.

    • Pass Auth Errors: The number of errors that the GWIA has encountered due to users entering invalid passwords. A high number here can be indicative of a hacker with a correct username attempting to guess at the mailbox password.

    • Denied Access Cnt: The number of times that the GWIA has denied mailbox access to a user attempting to authenticate. A high number here can indicate hackers guessing at mailbox IDs and passwords.

    • TCP/IP Write Errs: The number of errors that the GWIA has encountered attempting to write data to a TCP socket.

The next tool you will use to troubleshoot the GWIA is the GWIA's log file.


Understanding the GWIA Log

This section shows some sample sections of the GWIA log files, and explains how to interpret them. The goal is to help you understand what you see in your own GWIA logs so that you can more effectively administer your system.

Log Line Format

Each line in the agent log is divided into four main parts. The first of these is the timestamp, that is, the hour, minute, and second that the event in this log entry occurred.

The second part is the process number. This number identifies the server process or thread that performed the operation described in this log entry. If you are trying to follow a thread in the log, you must do so by finding the next occurrence of this number. If process 12 claims to be processing an outbound message, and then process 17 reports an MX lookup error, the error was not with the message in the previous line. Look for the next occurrence of process 12 to see whether the outbound message was processed correctly. Look for the previous occurrence of process 17 to see what it was doing before it got the MX lookup error.

The third part, which is not always present, is the process type. This string identifies the service engine that is currently active. When the GWIA is servicing POP3, IMAP4, or LDAP connections, this string will be POP3, IMAP4, or LDAP, respectively. SMTP processing is defined as the DMN process.

The fourth part of the log entry is the event description. This might seem a little bit cryptic, but after you have seen a few of them, you will be making sense of them easily. Events you'll see here include error messages, login IDs for POP3 or IMAP users, or descriptions of the conversion and transfer of SMTP/MIME messages.

Configuration Information in the GWIA Log

Here's the first block of text you will see in the GWIA log, the GWIA configuration:

00:41:58 2BA Starting GWTCP-Dispatcher
00:41:58 2BC Starting GWTCP-Monitor
00:41:58 2BE Starting GWPOP-Listener
00:41:58 2C0 Starting GWIMAP-Listener
00:41:58 28E Begin Configuration Information
00:41:58 28E   Platform= NLM
00:41:58 28E   Domain and Agent= GWIADOM.GWIA
00:41:58 28E   Foreign Name= wwwfs1.worldwidewidgets.com
00:41:58 28E   Description= <none specified>
00:41:58 28E   Alias Type= <none specified>
00:41:58 28E   Root Directory= WWWFS1/SYS:\GWIADOM\WPGATE\GWIA
00:41:58 28E
Work Directory= WWWFS1/SYS:\GWIADOM\WPGATE\GWIA\000.prc\gwwork
00:41:58 28E
Log File= WWWFS1/SYS:\GWIADOM\WPGATE\GWIA\000.prc\0505gwia.002
00:41:58 28E   Directory ID= gwi2c7

These first lines show that at 41 minutes after midnight the GWIA began reading configuration information. These lines correspond to information you might recall entering from the GWIA's Information property page. The GWIA indicates which directory it is working from. The log also includes the name of the current log file, as well as the directory ID of the GWIA. This directory ID is a directory within the DOMAIN\WPGATE\GWIA\WPCSOUT directory that the MTP portion of the GWIA will use to queue messages for the GWIA to send out.

The next five lines come from the GWIA's Optional Gateway Settings property page under the GroupWise drop-down tab:

00:41:58 28E   Directory Synchronization= NO
00:41:58 28E   Directory Exchange=        NO
00:41:58 28E   Accounting=                YES
00:41:58 28E   Convert GroupWise Status to Messages= NO
00:41:58 28E   Outbound Status Level= UNDELIVERED

You can see that accounting has been enabled, and users whose outbound messages cannot be transferred will get an Undeliverable status back.

The next lines show the logging level, recovery and retry settings, gateway correlation settings, polling intervals, and time zone information in effect for the GWIA:

00:41:58 28E    Log Level=     Verbose
00:41:58 28E    Log Max Age=   7 days
00:41:58 28E    Log Max Space= 34321 kb
00:41:58 28E    Enable Recovery=      YES
00:41:58 28E    Retry Count=          10
00:41:58 28E   Retry Interval=       5 seconds
00:41:58 28E   Failed Recovery Wait= 3600 seconds
00:41:58 28E   Network Reattach Command= <none specified>
00:41:58 28E   Correlation DB Enabled= YES
00:41:58 28E   Correlation DB Age=     14 days
00:41:58 28E
Correlation DB Directory= WWWFS1/SYS:\GWIADOM\WPGATE\GWIA
00:41:58 28E   Send/Receive Cycle=  2   minutes
00:41:58 28E   Minimum Run=         0   minutes
00:41:58 28E   Idle Sleep Duration= 30  seconds
00:41:58 28E   Snap Shot Interval=  10  minutes
00:41:58 28E   Time Zone= MST
00:41:58 28E   GMT Offset= -7 hours, 0 minutes
00:41:58 28E   Hemisphere= NORTH
00:41:58 28E   Daylight Saving Change= 1 hours, 0 minutes
00:41:58 28E   Daylight Saving Begin=  4/3 (month/day)
00:41:58 28E   Daylight Saving End=    10/30 (month/day)

Some of these settings come from the Optional Gateway Settings property page, some come from the Log Settings property page, and the time zone information is read from the appropriate time zone definition in the domain database.

In this last set of configuration entries, the log says that the GWIA will not use a second processor (SMP Off) and that it will publish Simple Network Management Protocol (SNMP) information:

16:12:41 1  SMP Off
16:12:41 1  SNMP On
16:12:41 1  Startup Switches= /Home-\\WWWFS1\MAIL\GWIADOM\WPGATE\GWI
16:12:41 1   A /DHome-\\WWWFS1\MAIL\GWIADOM \WPGATE\GWIA /SMTP /LDAP
16:12:41 1    /MIME /MUDAS=2 /MailView-Internet /SD-16 /RD-8 /P-10
16:12:41 1    /TE-2 /TG-5 /TC-5 /TR-5 /TD-3 /TT-10 /PT-30 /IT-30 /
16:12:41 1   LdapThrd-10
/ST-4 /RT-4 /IRFOUID /SMP /LDAPcntxt=WWWIDGETS
16:12:41 1   S /POP3 /IMAP4
16:12:41 1  End Configuration Information
16:12:41 1  MTP: Message Transfer Protocol initialization...
16:12:41 1  MTP: Queue initialization...
16:12:41 1  MTP: Queue initialization...
16:12:41 1  Starting GWPOP-Handler_1
16:12:41 1  Starting GWIMAP-Handler_1
16:12:41 1  End Configuration Information

The log also shows all the startup switches that have been written to the GWIA.CFG file. These switches govern the number of threads for the various services, among other things. Finally the log shows that the MTP, POP, and IMAP threads of the GWIA are initialized.

Message Processing Log Entries

When the GWIA processes a message that was sent from a GroupWise user to a recipient on the Internet, the log entries look a lot like this:

 1. 08:01:30 7 MSG 6 Processing outbound message...
 2. 08:01:30 7 MSG 6 File: ERAFF1/MAIL:\GW6\DO1\WPGATE\GWIA\wpcsout\gwif
    94a\4\4EF956D2.M80 Message Id: (3EF9AB2B.B51:8:40818) Size:
    455
 3. 08:01:30 7 MSG 6 Sender: ecornish@wwwidgets.com
 4. 08:01:30 7 MSG 6 Converting message to MIME: ERAFF1/MAIL:\GW6\DO1\WP
    GATE\GWIA\send\xef956d8.001
 5. 08:01:30 7 MSG 6 Recipient: glenn@brown.com
 6. 08:01:30 7 Switching link state to SENDING_ALLOWED.
 7. 08:01:30 7 MSG 6 Queuing message to daemon: ERAFF1/MAIL:\GW6\DO1\WPG
    i. ATE\GWIA\send\sef956d8.001
 8. 08:01:30 7 DMN: MSG 7 Sending file: ERAFF1/MAIL:\GW6\DO1\WPGATE\GWIA
    i. \send\pef956d8.001
 9. 08:01:30 7 DMN: MSG 7 Connected to mail-mx.brown.com
10. 08:01:30 7 DMN: MSG 7 Transferred

Let's break down the 10 log lines from one piece of mail being sent from ecornish@wwwidgets.com to glenn@brown.com.

Line 1 GWIA reports that it is processing an outbound message. Notice that the GWIA assigns a MSG ID of 6 to this message.

Line 2 Displays that the GWIA is picking up a message from its input queue. The MTA placed the message here. One very helpful piece of information is the Message ID: (3EF9AB2B.B51:8:40818). This value will exactly match the user's sent items. If you were to look at the user's sent item properties, this is the identifying Message ID that will never change as the message flows through the GroupWise system.

Line 3 This identifies the sender of the message.

Line 4 This line shows the GWIA converting the message into SMTP MIME format and placing it in the GWIA SEND directory. Notice that the file begins with an X. This means the GWIA SMTP daemon is "hands off" as the conversion process is happening.

Line 5 This identifies the recipient. In this example, it is glenn@brown.com.

Line 6 GWIA switches into sending state.

Line 7 The X locked message that is in the SEND directory is unlocked. The filename now begins with an S, which signifies that the SMTP daemon can grab it and send it to the destination SMTP daemon.

Line 8 The GWIA begins sending the SMTP message to the destination SMTP gateway. At this point the filename begins with a P for "processing." This means the GWIA is in the process of sending it out, and has its hands on it.

Line 9 This shows that the GWIA has done a DNS lookup for brown.com and identified the destination SMTP server as mail-mx.brown.com, and is connecting to it.

Line 10 This shows the message as being transferred to the destination SMTP gateway.

The logging of the GroupWise 7 GWIA is much improved, and this is easily double the amount of logging about a sent message that the GroupWise 6 GWIA reported. You can much more easily identify that this message was successfully transferred to the destination SMTP gateway.

As you can see, from the GWIA log you can see exactly which users on your system are sending mail to Internet users, and you can capture every address. You can also see which Internet users are sending email to which users on your system. We know of at least one case in which information from a GWIA log has been used to expose users who were selling company secrets to the competition. Your users might consider this to be an infringement on their privacy, so you should be sure to word your organization's email policy in such a way as to allow you to scan GWIA logs freely.

Here's a look at what happens with an SMTP error:

13:54:13 0 Analyzing result file: r83a9c7e.084
13:54:41 0 Analyzing result file: r83a9c5d.083
13:54:41 0   Command: stribling.com
13:54:41 0   Response: 250 ok
13:54:41 0   Command: HELO mail.wwwidgets.com
13:54:41 0   Response:
250 Hello mail.wwwidgets.com [137.65.55.211], pleased to meet you
13:54:41 0   Command: MAIL FROM:<edekorte@wwwidgets.com>
13:54:41 0   Response: 250 <edekorte@wwwidgets.com>.. Sender ok
13:54:41 0  Detected error on SMTP command
13:54:41 0   Command: RCPT TO:<darren@stribling.com>
13:54:41 0   Response: 420 TCP read error

This file shows that process 0 analyzed a result file named r83a9c7e.084. This result file corresponds to an SMTP communication. Because there's no more information about this result file, you know that the communication was error free.

In the second line, process 0 picks up another result file to analyze, and this one has an error in it. Scanning through the available information, you can see that user edekorte@wwwidgets.com sent a message to darren@stribling.com. The GWIA looked up and then opened a connection with the stribling.com mail host. You can see this from the successful HELO commands and the success of the first MAIL command. Unfortunately, the GWIA got a TCP read error trying to transmit the recipient address. This indicates that the connection between wwwidgets.com and stribling.com is too noisy, was dropped, or timed out.

Unfortunately, the result file does not indicate what time these events occurred. What is visible is the GWIA's analysis of the SMTP daemons actions after the fact.

POP3 Connection Log Entries

Each time a user initiates a POP3 connection with the GWIA, that action is logged. Here is a sample of such a connection:

13:53:59 8 Accepted POP3 connection with: 10.10.40.232
13:53:59 8 POP3 Command: USER ksorensen
  13:53:59 8
   Successful login with
   client/server access:
   wwwfs1.wwwidgets.com:1677

13:53:59 8 POP3 Command: PASS
13:53:59 8 POP3 Command: STAT
13:53:59 8 POP3 Command: QUIT
13:53:59 8 POP3 Session ended: 10.10.40.232

Process 8 handled the entire connection, as to be expected, because the GWIA can have only as many simultaneous POP3 sessions as it has POP3 threads. The log shows the IP address of the user workstation that is running the POP3 mailer, and then the log indicates which POP3 commands were issued. The entire POP3 connection lasted only a second, and then process 8 was free to service another connection or return to the pool of idle threads.


Configuring Dial-Up Internet Access

Some organizations might not have the luxury of a permanent connection to the Internet. In these cases, you can configure the GWIA to dial an Internet service provider (ISP) for temporary connectivity. The requirements for such a connection are the following:

  • The ISP must provide ETRN service, as per RFC-1985.

  • The ETRN hostname provided by the ISP must have a static address.

  • The IP stack on the GWIA server must be able to dial the ETRN host. This can be accomplished with BorderManager on NetWare servers or Dialup Networking on Windows servers.

If these requirements have been met, the procedure for configuring dial-up SMTP access for the GWIA is as described here:

1.
Open the SMTP/MIME Settings property page on the GWIA and click the Dial-Up Settings page. The dialog box shown in Figure 10.18 appears.

Figure 10.18. Enabling dial-up access from the SMTP/MIME Dial-Up Settings property page

[View full size image]

2.
Check the box labeled Enable Dial-Up.

3.
Under ETRN Host, enter the name of the ISP's ETRN host.

This is the name of the host that will be receiving email for your GWIA when your GWIA is not connected.

4.
Under ETRN Queue, enter the foreign name of the GWIA.

This must be the same as the domain name that your ISP has assigned you. This is the queue the ETRN host will use to identify the GWIA when the GWIA connects to collect messages.

5.
Click OK.

6.
Go to the Scheduling property page under the SMTP/MIME tab.

7.
Highlight Default and click the Edit button.

8.
Enter the appropriate thresholds. For example, you could configure the GWIA to dial the ETRN host if there are 10 messages queued, if there is at least 500KB of mail queued, or if the oldest item queued has been waiting at least 30 minutes.

9.
Set the polling interval, under Dial parameters, to the minimum amount of time you want the GWIA to wait before checking the ETRN host for inbound mail. Because the longest you want an outgoing message to be waiting is 30 minutes, set this number to 30 minutes also. This is just an example, though; do what is best for your system.

10.
Click OK.

11.
With the new profile selected, block out the hours of the day during which you want this profile to be in force.

You should probably select all hours of the day, on all days of the week. You can also create additional profiles for lower frequency dial-up after hours or on weekends.


Monitoring the GWIA Through a Web Browser

The GWIA allows you to monitor it though a Web browser. The GWIA must be configured for HTTP monitoring, as discussed earlier in this chapter.

When the GWIA is configured for HTTP monitoring, you can monitor it using the following syntax:

http://gwia IP Address or DNS Name:HTTPPORT defined in ConsoleOne

For example, here is one sample string:

http://137.65.55.211:9500

You are asked to authenticate to the GWIA using the user ID and password specified in the ConsoleOne. Then you will see a screen such as the one in Figure 10.19.

Figure 10.19. Monitoring the GWIA through a Web browser can be easier due to the layout of the screen

[View full size image]

The monitoring shows statistical information, but what's really neat is that the entire configuration of your GWIA is all laid out on the Configuration page. It's easier to see how your GWIA is configured in the HTTP monitoring screen than it is through ConsoleOne.


GWIA Configuration Files

The GWIA is a bit of a strange duck in that it has several sources of configuration. Each configuration source has its own express purpose. This section lists some basic information about the purpose of these configuration sources:

  • WPDOMAIN.DB

    This is the domain database; the GWIA accesses this database for all kinds of GroupWise system information and general gateway configuration information.

  • GWIA.CFG

    This is the main configuration file for the GWIA. Many of the changes you make in ConsoleOne are written to the GWIA.CFG file. There are several features in the GWIA.CFG that are not mapped into fields in ConsoleOne. These settings have to be enabled by editing the GWIA.CFG. The most up-to-date information on the switches that can be added to the GWIA.CFG is at Novell's documentation site (www.novell.com/documentation).

  • MIMETYPE.CFG

    This file lists the various mime file types that the GWIA will recognize. New mime types can be added. Look at Novell's Knowledgebase for more information on this file.

  • FRGNAMES.CFG

    This file is where you would add all the Internet domains (idomains) that the GWIA should listen for. As mentioned before, this file is quite often not used anymore, because you can now enter as many Internet domains as you want via ConsoleOne, as described in Chapter 16. Look at Novell's Knowledgebase for more information on this file.

  • ROUTE.CFG

    This file is where you can add DNS Mail Exchange (MX) record overrides. So, for example, if you do intend for your GWIA send to ACME.COM but you do not want the GWIA to send to the publicly advertised MX record, then you would indicate the IP address for an SMTP that you want to send messages for ACME.COM to. Look at Novell's Knowledgebase for more information on this file.

  • GWAUTH.CFG

    This file is where you can add overrides that allow another host to relay through the GWIA. There are some other purposes for the GWAUTH.CFG. As of the writing of this book, the best place for information on the GWAUTH.CFG is Novell's documentation site (www.novell.com/documentation).

  • BLOCKED.TXT

    This file is appended to by the ConsoleOne snap-ins when you exclude certain hosts from sending to your GWIA. This file is created and edited when you define hosts in the GWIA's configuration under Access Control, SMTP Incoming, Do Not Allow From.

  • XSPAM.CFG

    This is where you can define information regarding XSPAM headers and Junk Mail Handling. We'll wait to discuss this file fully in Chapter 25.


Best Practices

It is difficult to make recommendations for GWIA implementation without first discussing GroupWise Internet addressing. Because Chapter 16 covers Internet addressing in detail, We suggest that you review the best practices there before installing or configuring the GWIA. Here are a few recommendations, however:

  • Dedicate a domain to the GWIA: We discuss default GWIAs and routing domains more in Chapter 16. For now, it is enough to say that if you have heavy Internet traffic (more than 30,000 messages per day), you might want to offload that traffic from your other production domains. Create a domain with no post offices, and dedicate a machine to running just that domain's MTA and the GWIA.

  • Strongly consider Access Control features: There are some great features under Access Control. For example, under the Default Class of Service, you should control the maximum mail message size that users can transmit via the GWIA. If you do not do this, users might end up using the GWIA as an FTP utility (effectively), which isn't an efficient use of the server. You can also create a special profile and add a few key users (such as yourself <grin>) who are able to send larger files than the users under the Default Class of Service.


Summary

GWIA is a critical piece of any GroupWise system. Without the GWIA, your GroupWise users don't have Internet email, and they don't have the capability to use their POP3 or IMAP4 mail programs. This chapter showed you how to install and configure the GWIA. This chapter also explained the meaning behind the entries you will find in the GWIA log files.


Chapter 11. Installing and Configuring GroupWise WebAccess

This chapter explores the aspects of WebAccess in relation to a GroupWise system. GroupWise provides several options for users to access their mailboxes via the Internet. Having a good understanding of WebAccess will prepare you to set up and maintain a reliable implementation of WebAccess in your GroupWise environment.


Understanding WebAccess Architecture

To understand the WebAccess component of your GroupWise system, it is important to understand the WebAccess architecture. This will help with installing, configuring, and troubleshooting the WebAccess components.

Understanding the WebAccess Agent

WebAccess is composed of three main pieces: the agent, the document viewer, and the application. The first piece is referred to as the WebAccess Agent and is responsible for requesting and receiving data from a user's mailbox. This WebAccess Agent can run on NetWare as an NLM (GWINTER.NLM), on Windows 2000/2003 as an executable (GWINTER.EXE) or as a Windows 2000/2003 service, and on Linux (gwinter). You can think of the WebAccess Agent as a client that communicates directly via TCP/IP with a post office agent (POA) via its client/server port, such as 1677.

Understanding the WebAccess Document Viewer Agent

A new process in GroupWise 7 is the Document Viewer Agent, which will transform all attachments into HTML viewable content, something previously handled by the WebAccess Agent itself. With the document-viewing task being a separate process, a corrupt or unwieldy attachment will not have an adverse impact on the WebAccess Agent. Historically in prior versions of GroupWise, the WebAccess Agent could be problematic in environments with large or corrupt mail message attachments. The Document Viewer Agent makes such problems a thing of the past.

Understanding the WebAccess Application

The third main part of WebAccess is referred to as the WebAccess Application. It is responsible for taking the data received by the WebAccess Agent and delivering it to the user's web browser that is being used to access WebAccess. The WebAccess Application runs on a web server as a Java servlet. It runs on any of the following supported web server platforms:

  • Apache Web Server 1.3 plus Tomcat 3.3 plus the Jakarta Connector for NetWare 6.0

  • Apache Web Server 2 plus Tomcat 4 plus the Jakarta Connector for NetWare 6.5 or Linux

  • Microsoft Internet Information Server (IIS) 5 or later plus Tomcat 5.5 plus the Jakarta Connector for Windows 2000 or Windows 2003

  • Apache 2 (or higher) plus a compatible servlet engine and connector for UNIX

Tip

Although you can still use Apache 1.3 plus Tomcat 3.3 on NetWare 6, we strongly advise you to consider upgrading your Apache services to Apache 2 plus Tomcat 4. This newer version is more robust and less prone to security attacks. Also, we strongly advise you to keep all of your web servers up-to-date, because we've seen issues with security leaks with nonup-to-date servers.

The WebAccess Application communicates with the WebAccess Agent via TCP/IP. By default, the WebAccess Agent listens on port 7205 for information coming from the WebAccess Application. The data that is exchanged between the Agent and the Application is encrypted using an encryption key. This is not your standard SSL type of encryption, but simply an encryption key that each piece (Agent and Application) uses to encrypt data between them. The encryption key is discussed later in this chapter in the section "Configuring the GroupWise WebAccess Gateway."

Understanding the WebAccess Process

Let's quickly see how a request coming in from a web browser in order to log in to a GroupWise mailbox would act. This will help you understand the flow of information through a WebAccess system, as well as help you see the relationship between the WebAccess Application and Agent:

  1. A user enters the URL to GroupWise WebAccess into her browser. For example, the URL might be http://groupwise.wwwidgets.com.

  2. The browser is directed to the web server that DNS resolves them to. The user then sees the GroupWise WebAccess login screen. (There are lots of options as to what you will have your users doing; for simplicity, the web server at http://groupwise.wwwidgets.com goes directly to the WebAccess login screen.) This screen is a standard HTML document that the web server is displaying. Figure 11.1 shows this screen.

    Figure 11.1. The GroupWise WebAccess login screen

  3. The user enters a user ID (in the Username field) and password and clicks Login.

  4. The web server hands this information over to the WebAccess Application that is running as a Java servlet on the web server. The servlet also detects the platform and manufacturer of the browser, and creates a session for this user, using the correct template types based on the browser type.

  5. The WebAccess Application takes the user ID and password and determines which WebAccess Agent it should route the request to. It discovers that it needs to send the request to an IP address of X.X.X.X on port 7205.

  6. The WebAccess Application encrypts the data using the encryption key found on the local web server and sends the username and password to the WebAccess Agent running on a NetWare, Windows, or Linux server via port 7205.

  7. The WebAccess Agent receives the data, decrypts it using the same encryption key that was used to encrypt the data, and then does a lookup in the WPDOMAIN.DB to identify the domain and post office where the user is.

  8. After the user's domain and post office are located, the WebAccess Agent determines how it will communicate with this particular post office. It discovers that it must communicate via TCP/IP.

  9. The WebAccess Agent sends the user ID and password down to the POA object for the user's post office, and acts like a traditional GroupWise client, in that it connects to the POA via client/server port 1677. The POA picks up the request and authenticates the user into the mailbox.

This represents a quick and simple outline of how a user's request flows from an actual browser into a GroupWise mailbox. At this point, we don't discuss the return path of the data from the post office to the web browser. Basically, the return path for the data coming from the post office is in reverse order, minus a few of the lookups, because a session ID is in place to route the data back from the Agent to the Application.

This should give you a basic understanding of how the WebAccess Application and the Agent work together to access the user's mail via WebAccess. Now that you have an understanding of GroupWise WebAccess architecture, you're ready to install GroupWise WebAccess.


Installing the GroupWise WebAccess Gateway

There are many ways to make your WebAccess Gateway redundant, but before we discuss these options, we need to discuss a basic install of a simple GroupWise WebAccess installation. This section includes some behind-the-scenes information you might find beneficial.

Note

WebAccess can run only on a functional web server, so you need to make sure that a suitable web server is installed and running on your server. The supported web servers are listed in the preceding section.

This example describes the simple installation of the WebAccess Agent and Application onto a single NetWare server. This is a very common scenario and the information provided is also useful for the installation of WebAccess on Windows or Linux. The section "Advanced Installation Options for WebAccess" contains additional information about installing the Agent and Application on different servers. For now, this section provides a good understanding of the install options for the Agents and Application.

Starting the Installation of the GroupWise WebAccess Gateway

To start the installation of the GroupWise WebAccess Gateway, follow these steps:

1.
Map a drive to the server that will run the WebAccess Agent, and also map a drive to the server that is running the web server.

2.
Launch the SETUP.EXE from the INTERNET\WEBACCES directory located in your GroupWise Software Distribution Directory or GroupWise CD.

Accept the license in the license screen and choose to install the WebAccess Agent and Application options, as shown in Figure 11.2. If you are using GroupWise Document Management (GroupWise Libraries) and either are currently using WebPublisher or want to add WebPublisher to your installation, choose that option as well.

Figure 11.2. Choosing which GroupWise WebAccess components to install

[View full size image]

3.
The WebAccess Agent and Application were discussed earlier. The WebPublisher Application is used to access documents stored in GroupWise document management libraries. If you are using GroupWise document management, you might want to enable the WebPublisher Application. This example does not include installing the WebPublisher Application.

You have now successfully completed this part of the installation.

Installing the GroupWise WebAccess Agent

The next few steps will install the WebAccess Agent, in this case as part of a complete installation of WebAccess. The agent can also be installed as a separate module; just follow these same steps:

1.
Choose the platform and file location for your WebAccess Agent. You might want to use a drive-letter mapping, because a UNC path doesn't always work well. Click Next.

During this step, you've defined the path to the server where the WebAccess Agent will be installed. As mentioned before, the Agent can run on NetWare, a Windows 2000/2003 server, or a Linux server. This step also determines which code the install script will install. If you select NetWare as the platform, GWINTER.NLM is installed for the Agent. If select Windows, GWINTER.EXE is installed. There are, of course, additional files installed, but the GWINTER is the main workhorse for the Agent piece. The directory specified here can be eight characters or fewer.

2.
Choose the IP address or DNS name for the WebAccess Agent.

Y ou are now prompted to enter the IP address or DNS name of the server on which you are installing the Agent. The install script tries to auto-detect this information for you and displays it, as shown in Figure 11.3. Before this screen, though, the first thing the script does is query the server that you defined in the preceding step to verify whether any GroupWise modules are loaded. If they are, you are prompted to unload the GroupWise modules.

Figure 11.3. GroupWise WebAccess Agent server information includes a supplied IP address and related information

[View full size image]

Tip

On NetWare, the DNS hostname comes from the HOSTS file found in the SYS:\ETC directory. Before proceeding, make sure that the local HOSTS file on the web server contains the local IP address and a web server name. This information can appear anywhere in the HOSTS file.

137.65.55.211 groupwise.wwwidgets.com

If the DNS name is incorrect, the HOSTS file is where this information is coming from.

The information about the DNS name and IP address of the server is used to help create a binary file on the web server called COMMGR.CFG, which the WebAccess Application reads to determine on which server and port the WebAccess Agent is installed. This information is also placed into the GroupWise WPDOMAIN.DB to notify the WebAccess Agent which port it should listen on for connections coming from the WebAccess Application.

Tip

Note the option to cluster-enable the WebAccess Agent. Checking this box simply changes the definition of the path to the WebAccess Agent when the Agent loads. You will see an example of what checking this cluster option does in the next section, which talks about how to load the WebAccess Agent. If you are installing this WebAccess Agent into a Novell cluster, you will want to check this box. If you do check the option to configure the GroupWise Agent for clustering and you are not running in a cluster environment, don't worry. The Agent will load just fine on a non-clustered server.

3.
After confirming the server information for the server that will run WebAccess Agent, click Next. You will see the screen shown in Figure 11.4.

Figure 11.4. GroupWise WebAccess Agent gateway directory configuration

[View full size image]

You are now prompted for the path to the domain. Once again, the install script tries to provide this information for you; however, it might not be correct. The path to the domain you see here comes from the workstation's Registry that you are running the install from. Notice that it gives you the full path of where the gateway directory will be. GroupWise stores all the gateway directory structures in DOMAIN\WPGATE\. Hence, you will see this in the gateway directory's full path information.

Tip

Keep this directory within eight characters or fewer. The install script will check to make sure that the directory exists; if it does not, it will prompt you to create it. If it does exist, you might be asked whether you are sure you want to use this directory.

4.
After specifying the gateway directory, click Next.

You are now asked what you want the WebAccess Agent gateway object to be called. This is the object you will see from ConsoleOne under the GroupWise domain defined earlier. For simplicity, it is best to keep these names the same.

The next step, shown in Figure 11.5, might have you wondering why this is necessary. You're queried for a username and password so that the gateway can access the WPDOMAIN.DB of the WebAccess Agent's domain. It's a good idea to place the domain and WebAccess Agent on the same server. Hence, a username and password are not necessarily required. However, the install requires you to enter a username and password here. The main reason for this is that if your domain is on FS1 and you are installing the WebAccess Agent on FS2, the Agent must be able to directly access the WPDOMAIN.DB to read some of its configuration information. Because of this, the Agent must log in to the FS1 server to access the domain database. Also, if the Agent must communicate to post offices via a direct link, it will use this username and password to authenticate to the post office server.

Figure 11.5. Username and password are required for the GroupWise WebAccess Agent

[View full size image]

5.
After entering the username and password, click Next.

The next screen gives you the option to monitor the WebAccess Agent through a standard HTTP browser. This allows you to check in with your WebAccess Agent to see how it is running without having to actually look at the Agent console screen. However, you should of course not allow everybody to have access to this information, so you can protect it with a username and a password. This user does not have to be an eDirectory account; it can be just an arbitrary separate username and password.

6.
Check the Enable Web Console option and enter the details for the monitor account (see Figure 11.6). Click Next to proceed to the WebAccess Agent installation summary screen. Or you may want to consider not checking the Enable Web Console option, and entering the information from within ConsoleOne after the WebAccess Agent is installed. This is our preference.

Figure 11.6. Specify the username and password for monitoring the GroupWise WebAccess Agent via HTTP. This should not be an eDirectory or a GroupWise account

[View full size image]

You will get one additional prompt about the WebAccess Agent supporting the WebPublisher. This example doesn't install WebPublisher. If you are installing WebPublisher, you would want to enable this check box.

7.
You now see a summary of the WebAccess Agent setup information. Verify that all information is entered correctly, and click the Next button.

This concludes the WebAccess Agent portion of the install. The wizard now takes you directly into the WebAccess Application wizard install.

Installing the GroupWise WebAccess Application

The next few steps will install the WebAccess Application on the web server, in this case as part of a complete installation of WebAccess. The applications can also be installed as a separate module; just follow these same steps.

Note

The WebAccess Application is the piece that runs as a servlet on a web server and communicates to the WebAccess Agent via TCP/IP.

The first thing you are prompted for in the WebAccess Application install process is what type of web server you will be installing the Application on. Follow these steps to complete the WebAccess Application install process:

1.
Select the web server platform, verify that the path to the root of the web server is correct, as shown in Figure 11.7, and then click Next.

Figure 11.7. The first choice of the WebAccess Application install asks which web server to install the application to

[View full size image]

2.
Configure the IP address or DNS server name, as shown in Figure 11.8, and then click Next.

Figure 11.8. Specify the DNS name or IP address of the WebAccess Application

[View full size image]

Tip

WebAccess no longer uses the novell.html file that earlier versions of GroupWise installed in your web server's HTDOCS directory. If users have been accessing the WebAccess client by displaying the novell.html file, the links in that file no longer work. You should remove the obsolete novell.html file from the HTDOCS directory and use the new URL to access the WebAccess client. If you have customized the novell.html file, you can transfer your changes to the index.html file in the sys:tomcat/4/webapps/gw directory.

3.
Select the web server default web page option you prefer, and click Next.

You are then prompted as to where you want the configuration files for the WebAccess Application to be located. This defaults to the <\\SERVER NAME\SYS\NOVELL directory for NetWare, as shown in Figure 11.9. The install creates a WebAccess directory under the specified directory where the configuration files are actually placed. These configuration files should exist on the same server as the web server.

Figure 11.9. Confirm the directory for the WebAccess Configuration files

[View full size image]

Note

If this directory does not exist, you will be prompted to create it.

4.
Enter the path for the configuration files and click Next.

You are prompted as to which Java servlet gateway you will be using (see Figure 11.10). Take the default, unless you must use a different Java servlet gateway.

Figure 11.10. The Java servlet gateway runs the WebAccess Application

[View full size image]

5.
Select the servlet gateway and then click Next.

6.
Select the default language and click Next.

The next option (see Figure 11.11) asks in what context of your eDirectory tree the application objects should be created. These application objects consist of the GroupWise WebAccess object, the GroupWiseProvider object, the LDAPProvider object, and the NovellSpeller object. These objects, and the services they perform, are discussed more in the section "Configuring the GroupWise WebAccess Gateway." The default context is the context of the domain object. This is usually sufficient, as these objects should exist close to the domain for administration purposes.

Figure 11.11. Choosing an eDirectory context for WebAccess Application's objects

[View full size image]

Note

It might be a bit confusing to see the name of the GroupWise domain listed at the beginning of the context. Even though a GroupWise domain object is not considered an eDirectory organization or organization unit, which are your traditional container objects that would contain eDirectory leaf objects, the domain's eDirectory object has an attribute that defines it as a container object. Because of this, you can actually create some objects under the domainyou can create GroupWise gateways, service providers, and application objects. Therefore, it makes sense to have the context listed as the domain object. This makes it nice because in eDirectory you can then simply click the domain eDirectory object to view all the associated objects.

7.
Verify that the context is correct and click Next.

8.
You will see a summary of the WebAccess Application information that you entered. Verify this information and click Next.

9.
If prompted to unload Java, do so manually rather than allowing the installation to do so.

To unload Java manually from the NetWare console prompt, enter the following commands:

java -killall
java exit

10.
The install will then proceed to install the WebAccess Agent and Application. You might be prompted to overwrite older files. If so, you will want to keep the newest file.

The last thing you see is a summary screen with information on how to load the components that were just installed.

In the next section, you'll learn how to put on the final touches to the WebAccess Agent installation. If you leave the last options checked, the Install Wizard launches the WebAccess Agent and restarts the web server for you. This gives you a functioning WebAccess system.

Important GroupWise WebAccess Agent Configuration Steps

There are just a couple of settings you should make on the WebAccess Agent so that it will function correctly immediately. Here are the steps for configuring the last few essential WebAccess Agent settings:

1. | In ConsoleOne, edit the properties of the WebAccess Agent.
2. | Select the Post Office Links property page. Make sure that all links are client/server only and all the IP addresses of the POAs are filled in.
3. | Next, go to the GroupWise tab, and select the Log Settings property page.
4. | Change the logging level to verbose.
5. | Specify a log file path on the server that houses the WebAccess Agent. The default path is DOMAIN\WPGATE\WEBACCESS\000.PRC.
6. | Increase the max log disk space; for example, to 50000.

The reason you must specify a log file path is that the WebAccess Agent will not create a log file on the disk, unless you specifically indicate the path to create log files. This is a quirk with the WebAccess Agent that other GroupWise Agents do not have.

See Figure 11.12 for example of a configured Log Settings page.

Figure 11.12. WebAccess Agent log settings are important if you need to troubleshoot your GroupWise WebAccess Agent

[View full size image]


Loading the GroupWise WebAccess Agent and Application

This section discusses how to start the WebAccess Agent and WebAccess Application. The WebAccess Agent is one process and the WebAccess Application is two processes.

Loading the GroupWise WebAccess Agent

On NetWare, load the GroupWise WebAccess Agent by typing STRTWEB, which calls the STRTWEB.NCF file. You should also consider adding load commands to the server's AUTOEXEC.NCF file.

Tip

If you installed your WebAccess Agent files to a directory other than SYS:\SYSTEM, the STRTWEB.NCF file does not pick up this path when it loads GWINTER. You will need to modify the STRTWEB.NCF file to include the correct path to the GWINTER.NLM file.

For Windows servers, follow these steps: For Windows 200x, a shortcut called GroupWise WebAccess has been created for you, or the Agent has been configured as a service if you chose that installation option. Generally the shortcut is available under Start, Programs, Novell GroupWise WebAccess. A batch file called STRTWEB.BAT is created, and is installed in the C:\WEBACC directory by default. If the Agent has been installed as a service, you must start and stop the WebAccess Agent via the Windows Services found in Control Panel, Administrative Tools, Services.

Here's an explanation of what's in the STRTWEB.NCF file on a NetWare server. Following is a sample STRTWEB.NCF file:

Load SYS:system\gwinter @WEBAC70A.waa

When you load the WebAccess Agent, take notice that GWINTER.NLM auto-loads several other NLMs, starting with SC*.NLM, and several instances of GWDVA.NLM. As soon as a user views an attachment, one or more VS*.NLMs will be loaded as well. These NLMs are used when a user views an attachment that might be some sort of document type from the WebAccess client. The VS*.NLMs take very little server memory because only a small piece of them loads when you load the Agent. When a user needs to actually view a document, the entire viewer NLM loads at that point.

Note

On NetWare, the Viewer Agent requires at least 1GB of memory for running about five worker processes.

On NetWare, you must install the latest Support Pack for your version of NetWare in order to have the correct version of clib.nlm.

On NetWare, Memory Protection Fault Cleanup must be set to On for the Viewer Agent worker processes to recover successfully when a document fails HTML conversion.

On NetWare, when a document fails HTML conversion and its worker process dies, NetWare creates a small file named core*.dmp in the server's root directory. You should periodically delete these files.

The install also creates a STOPWEB.NCF file, which will shut down the WebAccess Agent. It simply contains the line UNLOAD GWINTER, which will unload the WebAccess Agent.

Following are some useful switches that can be used in strtweb.ncf or strtweb.bat (if you want to modify the startup file):

  • @filename: This switch allows you to place all startup switches in a particular file. This is similar to when a domain or post office agent is loaded. This switch is not used by default.

  • /help: If the GWINTER.NLM or GWINTER.EXE files are loaded with the /help switch, all startup switches are displayed with brief descriptions.

  • /maxusers-: Enter the maximum number of concurrent users that the Agent will support. The default is 250 users.

  • /user-: Enter any username here. The username is not actually used in most customer environments; the WebAccess Agent just requires that the switch be filled in.

  • /password-: Enter the password for the user defined in the /user- switch. The password does not actually need to be accurate in most customer environments.

  • /ip-: Enter the IP address that the Agent will bind to. The Agent will bind to the first bound IP address of the server by default.

Note

When you install the WebAccess Agent, it will create a startup file. This startup file is the name of the WebAccess Agent that you defined during the install (by default, WEBAC70A.WAA).

An example of a 7.0 STRTWEB.NCF file is load sys:system\gwinter @WEBAC70A.waa.

The WEBAC70A.WAA file contains most of the startup switches you might use on the WebAccess Agent, just like the message transfer agent (MTA) and POA startup files do. A sample WebAccess Agent startup file can be found at the following location: GroupWise 7 SDD\INTERNET\WEBACCES\config\AgentConfig.waa.

Loading the GroupWise WebAccess Application

With just the WebAccess Agent running, you have only one piece of the entire WebAccess system running. You need to get the WebAccess Application up and running as well.

To do so, load the web server and the servlet gateway. The instructions for loading the web server or servlet gateway are different based on the platform you are using. The WebAccess Application needs two components in order to work: a Java servlet gateway and a web server.

Tip

Generally it's a good measure to reboot the server with the web server on it after the installation. Sometimes the WebAccess Application will not seem to behave as it should. Look at the following web server tips for instructions on the steps you might need to take to load the components that support the GroupWise WebAccess Application.

Following are the steps for loading the GroupWise WebAccess Application. Choose the OS you are running the WebAccess Application on, and follow the instructions associated with that OS.

Apache Web ServerNetWare 6.5 Server Platform

To load Apache 2.x on a NetWare 6.5 server, simply type this command:

apache2

The command to unload Apache2 is as follows:

unload apache2

Tomcat Servlet GatewayNetWare 6.5 Server Platform

NetWare 6.5 Apache web servers use the Tomcat servlet engine. The command to load Tomcat 4 is the following:

TOMCAT4.NCF

The Tomcat servlet engine might not be loaded automatically with your Apache web server on the NetWare platform. The Tomcat servlet gateway can be loaded before or after the web server loads. To load the Tomcat servlet gateway, use the following command:

tomcat4

The commands to unload Tomcat are shown here:

java -killall
java -exit

Or if you need to be a little more careful because your server is using JAVA for things other than the Tomcat servlet gateway, you need to just kill the Tomcat process. To show and then kill the Tomcat process, use this command:

java -show

The JAVA SHOW command reports the process ID. You can then issue this command:

java killPROCESS_ID

So if the process ID for our Tomcat servlet gateway was 176 as reported by the JAVA SHOW command, our command line would read as follows:

java kill176

LinuxApache Web Server

On Linux there can be different ways to install Apache2, because it can be part of the Linux distribution or can be installed separately for GroupWise only. During the installation of WebAccess, you can choose to install into an existing web server or to create and install a separate instance of Apache.

To start Apache manually on a Linux server with a GroupWise installation of Apache, use the following commands:

/etc/init.d/novell-tomcat4 start
/etc/init.d/novell-httpd start

To stop Apache on such a server, use this:

/etc/init.d/novell-httpd stop
/etc/init.d/novell-tomcat4 stop

On Novell Open Enterprise Server Linux the installation of Apache is part of the operating system. To start WebAccess manually, you can use the following:

/etc/init.d/novell-tomcat4 start
/etc/init.d/apache2 start

To stop Apache on a Novell Open Enterprise Server, you can use this:

/etc/init.d/apache2 stop
/etc/init.d/novell-tomcat4 stop

The command paths to load Apache and Tomcat on the Linux server may be different based on the version of Linux you are using, but the syntax should be similar.


Logging In To the GroupWise WebAccess Client

Now that the Application and the Agent are up and running, you are ready to read mail. This section doesn't spend a lot of time on the actual WebAccess interface and all the available options.

To begin, you must launch your web browser and point it to the web server on which you installed the WebAccess Application. If you replaced the default home page, you can simply enter http://your web server DNS name, and the language page for WebAccess should be displayed. If you did not replace your default web page, you can enter http://your web server DNS name/gw/webacc, and the login page will be displayed. You can then enter a GroupWise user ID and password and click Login.

Tip

WebAccess users are required to have passwords on their GroupWise accounts in order to log in via the WebAccess client. If your POA is configured to query eDirectory via LDAP, users can also use their eDirectory passwords if they have not assigned a password to their GroupWise mailboxes.

You should now be viewing your GroupWise master mailbox from the WebAccess client. Figure 11.13 displays a GroupWise 7 user's mailbox as viewed from the WebAccess client.

Figure 11.13. The GroupWise WebAccess client

[View full size image]


Configuring the GroupWise WebAccess Gateway

In this section, you'll learn about some of the eDirectory objects associated with the WebAccess gateway, what functions they perform, and how to configure all aspects of the WebAccess gateway. This section goes through each configuration screen, discussing most of the options and how they affect the overall performance or functionality of the WebAccess gateway. This section does not discuss every option, because some of the options are self-explanatory and make minor changes to the functionality of WebAccess. Also, there are a few generic gateway options of minimal consequence that will not be discussed.

The WebAccess Agent

This is the object you can see associated with a domain when you select to view gateways. It is the only object associated with a WebAccess gateway that is directly associated with a domain. When you edit the properties of the WebAccess Agent, you can configure the settings associated with this agent.

GroupWise Identification Property Page

Following is an explanation of the Identification property page of the GroupWise WebAccess Agent:

  • Subdirectory: This is the directory of the owning domain for the agent. It's located under the WPGATE directory. If you select the drop-down button, you will see all the gateway directories under this gateway. This should be the directory that the WebAccess Agent uses for some of its configuration files.

  • Time Zone: This allows you to enter the agent's default time zone.

Tip

Users can adjust the time zone from the WebAccess client so that appointments will show up in their local time zone.

  • Platform: You should specify on which platform this WebAccess Agent will be running. If you are running the agent on a Windows 2000/2003 or Linux platform, you will need to change this to reflect that OS.

  • Gateway Alias Type: For the WebAccess gateway, you should not need an alias type. This field is active on any of the GroupWise gateways.

  • Foreign ID: For the WebAccess gateway, you should not need a foreign ID. Again, this field is active on any of the GroupWise gateways and is primarily used with a GWIA.

  • SNMP Community "Get" String: If you are using SNMP-monitoring software to monitor the WebAccess gateway, this field allows you to set the get string to match your monitoring software. Blank is the default.

Network Address Property Page

Following is an explanation of the Network Address property page of the GroupWise WebAccess Agent:

  • TCP/IP Address: This should be the TCP/IP or DNS address for the WebAccess Agent.

  • HTTP Port: The HTTP port is used by the WebAccess Agent and the GroupWise Monitor utility. This port tells the WebAccess Agent which port to listen on for Web-browser monitoring. This GroupWise Monitor utility reads the HTTP port value from the domain database in order to monitor the WebAccess Agent.

    Tip

    To enable HTTP monitoring, you should also enable the HTTP username and password. To do this, go to the Optional Gateway Settings property page and fill in the HTTP username and password fields.

    The SSL portions of this screen are not discussed in this chapter. Chapter 27, "Securing Your GroupWise System via SSL," provides detailed information about how to enable SSL for WebAccess.

  • TCP Port: This is the port that the WebAccess Application running on the web server will use to communicate data to the WebAccess Agent. In other words, the agent will listen on this port for data coming from the application.

Configuring the GroupWise Optional Gateway Settings Property Page

Most optional gateway settings are generic gateway settings that do not apply to the WebAccess gateway. The help file regarding them should suffice. Be sure to fill in the HTTP username and password fields.

Understanding the GroupWise Gateway Administrators Property Page

In the GroupWise Gateway Administrators property page, you can define a GroupWise user or group as the administrator for the GroupWise agent. The roles are generic roles for all gateways. The one role you might be interested in setting is the operator.

The operator role allows the defined user(s) or group(s) to receive mail messages when errors occur at the GroupWise agent. This helps alert you to problems with the gateway.

Note

The user whom you add as an operator must be a GroupWise user. Also, if you add a group or distribution list, its visibility must be set to system.

Configuring the WebAccess Settings Property Page

Shown in Figure 11.14, the WebAccess Settings property page is important to enabling the application and agent to communicate properly. Both settings are stored in the domain database and in the COMMGR.CFG file, which is located in two places. It is located in the DOMAIN\WPGATE\WEBACCESS directory for the WebAccess Agent, and a copy of this file is made available to the WebAccess Application on the web server, the default of which is \NOVELL\WebAccess. On a NetWare server, the NOVELL\WebAccess directory is generally in the root of the SYS:volume. On a Linux server, the commgr.cfg file will typically be located in the directory /opt/novell/groupwise/webaccess.

Figure 11.14. The WebAccess Settings property page

[View full size image]

Note

The COMINT.CFG file located in the DOMAIN\WPGATE\WEBACCESS directory is basically a live backup of the COMMGR.CFG file. If your COMMGR.CFG file becomes damaged or corrupt, you can copy the COMINT.CFG file to COMMGR.CFG.

When you make changes to the maximum-threads or encryption-key settings, three files will be updated. They are the COMINT.CFG and COMMGR.CFG files located at the DOMAIN\WPGATE\WEBACCESS directory, and the COMMGR.CFG file located on the web server in the \NOVELL\WebAccess directory.

Note

When you make changes to the maximum-threads or encryption-key settings, the COMMGR.CFG file in the \NOVELL\WebAccess directory is first backed up to COMMGR.CFG.1 and a new COMMGR.CFG file is placed here. For this reason, you might see several COMMGR.CFG.X files in your \NOVELL\WebAccess directory. This indicates when a change was made to the threads or encryption key.

Following is an explanation of the Settings property page of the GroupWise WebAccess Agent:

  • Maximum Threads: This setting allows you to increase or decrease the maximum number of threads that the WebAccess Agent will use for communication. If you find that your users are receiving slow responses when using WebAccess, you might need to increase this number. You can monitor your agent to see whether it has reached the maximum number of threads. You will learn how to identify how many threads the WebAccess Agent is using later, in the section "Understanding the GroupWise WebAccess Console."

  • Encryption Key: The encryption-key value defined here is used to encrypt data sent between the WebAccess Agent and the WebAccess Application provider. This ensures that communication between these two WebAccess components is encrypted and secure. As mentioned earlier in this section, this encryption key is stored in the COMMGR.CFG file. Because both the WebAccess Agent and the Application provider must use the same encryption key, the COMMGR.CFG file is accessible to them both.

    You can accept the default encryption key that the install generates, or you can use your own encryption key, if desired. If the Application cannot talk to the Agent, it is good to double-check the COMMGR.CFG file on the web server running the Application and the server running the Agent. You can manually copy the COMMGR.CFG file from the DOMAIN\WPGATE\WEBACCESS directory to the \NOVELL\WEBACCESS directory if you do have a communication problem between these two agents.

Configuring the Access Control Settings Property Page

The Access Control Settings configuration page allows you to determine who can use the WebAccess gateway to access the GroupWise mailbox. You can define multiple classes of service with corresponding members. The default class of service contains everyone and allows everyone access to the WebAccess Agent.

One of the most important settings under Access Control is the Timeout After setting. The default of 20 minutes is generally a good setting to keep. If you increase this setting, users may needlessly tie up resources on the WebAccess Agent when they have already closed their browser.

To edit the Timeout After value, do the following:

1. | Go to the Access Control page.
2. | Highlight the class of service you want to affect, which is typically the Default Class of Service.
3. | Click the Edit button.
4. | Modify the Timeout After X Minutes of No Use field to reflect your desired timeout length.

You have now successfully changed the timeout value.

Understanding the Access Control Database Management Properties Page

All the access control settings regarding classes of service and membership are stored in a database called GWAC.DB. This database is located in the DOMAIN\WPGATE\WEBACCESS directory. This database management tab allows you to validate and recover this database.

Following is an explanation of the Access Control Database Management property page of the GroupWise WebAccess Agent:

  • Validate Now: Clicking this option will basically run a structure check on the GWAC.DB file that reports any inconsistencies found in the database. It also tells you how many bytes, fields, and indexes it validated. If inconsistencies are found, you should perform a Recover Now operation on the database.

  • Recover Now: Clicking this option will basically run a structural rebuild of the GWAC.DB that will repair any structural damage in the database. The GWAC.DC file is used as a template file on how to structurally build the new GWAC.DB file.

This section spoke of how to fix the GWAC.DB. However, you will rarely have issues with the GWAC.DB file.

Configuring the Reattach Settings Property Page

The Reattach Settings tab is used when you are running the WebAccess Agent on a Windows 2000/2003 platform and when the links to the post office are direct (or UNC). (Post office links are discussed in the next section.) If you are running the WebAccess Agent on a NetWare platform or if the post office links are TCP/IP, you do not need this information. Remember that the WebAccess Agent acts like a client when it accesses the user's user and message databases. If the agent is running on Windows 2000/2003 and you have defined direct links to post offices, the 2000/2003 server running the agent must log in to the post office's server in order to access the message store. This facilitates the need to supply the following information.

Following is an explanation of the Reattach Settings property page of the GroupWise WebAccess Agent:

  • Tree: Enter the name of the eDirectory tree where the server that houses the post offices is located.

  • Context: Enter the full context of the eDirectory user who will be used to log in to the post office server.

  • User ID: Enter the ID of the eDirectory user who has rights to the post office directory. (This user must have read, write, create, erase, modify, and file scan rights to the post office directory.)

  • Password: Enter the password for the eDirectory user.

Customers who use NetWare will most likely not have to use the settings on this property page.

Understanding the Post Office Links Settings Property Page

The Post Office Links Settings tab is very important. It defines exactly how the WebAccess Agent will communicate to the post offices in the GroupWise system. Remember that the agent acts like a client in that it must access the post office message store to retrieve a user's mail.

Following is an explanation of the Post Office Links Settings property page of the GroupWise WebAccess Agent:

  • Domain Column: This defines the domain that the post office is under.

  • Post Office Column: This identifies the name of the post office.

  • Access Mode: This defines how the WebAccess Agent will access the post office. You have four options here:

    • Client/server and direct

    • Client/server only

    • Direct only

    • Follow P.O. (use current post office access)

If the access mode is set to Use Current Post Office Access (also known as "Follow P.O."), it depends on what the post office object access mode is set to. If it is set to client/server only, you will see an IP address or a DNS name in the Link column. If it is set to direct only, you will see the UNC path to the post office in the Link column. If it is set to client/server and direct, you might see either an IP address or a UNC path. You need client/server access from the WebAccess Agent to each post office.

Warning

It's not possible to have a post office set to allow client/server only on the access mode but have the WebAccess Agent set to a direct connection. If this were the case, users of the WebAccess client would not be able to log in to their post offices, because the post office would reject direct connections coming from the WebAccess Agent.

You can edit any of the post office links from this interface if they are not configured correctly. Simply highlight the post office you would like to edit and click the Edit Link button.

Notice that the Post Office Links Settings window defines what the access mode for the post office is currently set to so that you don't have to pull up the details of each post office object to find this information. Also, when you have Follow P.O. selected, you cannot modify the links; they are grayed out. This is because it will read the UNC path and IP address from the POA object record in the WPDOMAIN.DB and use it. If you select any of the other three options, you will be able to modify either the UNC path or the IP address and port.

Tip

When troubleshooting WebAccess to POA connectivity problems, go to the Post Office Links property page first. Quite often, WebAccess will have the incorrect IP address or port for the POA. Somehow, when a POA's IP information or a post office's access method is updated, it is not always communicated well enough to WebAccess. Making the change from the Post Office Links property page is often the solution.

Configuring the WebPublisher Settings Property Page

These settings are used only if you installed the WebPublisher piece of WebAccess during the initial gateway install. Here's an explanation of these options so that if you are running GroupWise document management, you can configure this piece of the WebAccess gateway.

Following is an explanation of the WebPublisher Settings property page of the GroupWise WebAccess Agent:

  • WebPublisher Proxy User Mailbox ID: This is the GroupWise mailbox ID of a GroupWise user who will actually be retrieving documents in the GroupWise system. Document management users must share their documents with this particular proxy user in order for them to view these documents from WebPublisher. The proxy user is just a GroupWise user created in your system, for the express purpose of supporting WebPublisher.

  • WebPublisher Proxy User Mailbox Password: Enter the Proxy user's GroupWise password here.

  • Library Access: Here is where you define which libraries will be visible from WebPublisher. If you have multiple libraries in your GroupWise system, you can allow or restrict access to these libraries for the WebPublisher agent.

  • Assign General User Access to WebPublisher Users: If you enable this option, documents in the available libraries that are accessible to general users are available through WebAccess. In other words, if a user creates a document and this particular document type is accessible by all users, the WebPublisher proxy user would be able to see it, so the document would be available through WebPublisher. The owner of the document would not need to explicitly share it with the WebPublisher proxy user.

  • Disk Cache Size: This setting determines the size of the disk cache where cached documents will reside. When a user retrieves a document from a GroupWise document management library from within WebPublisher, the document will be cached. This setting determines how large this cache can grow to.

  • Cache Synchronization Interval: This value in seconds determines how often the WebPublisher Application will synchronize the document(s) in the cache with the real document sitting in the GroupWise library.

  • Disk Cache Path: This defines the location of the cache for documents that are retrieved via WebPublisher. It is recommended to have this directory located on the same server as the one where the WebAccess Agent is running. The default location for this cache on a NetWare server is SYS\SYSTEM\CACHE.

You should now be comfortable configuring the WebAccess Agent and should understand how these settings can affect the performance and functionality of your WebAccess Agent.

The next section discusses the eDirectory objects that are created with the WebAccess Application installation. It is through these eDirectory objects that you administer the remaining components of the WebAccess gateway.


Configuring the WebAccess Agent Subcomponents

As already explained, there are three main components of WebAccess: the Agent, the Document Viewer, and the Application. To be technically correct, the WebAccess Application refers to several subcomponents that work together to make up the WebAccess Application. One of these components is referred to sometimes as the servlet component, and the others are referred to as the service provider components. These two sets of components work together in regard to the WebAccess Application.

You might have noticed that there was an option called the WebPublisher Application. Think of the WebPublisher Application as a mirror piece to the WebAccess Application with minor differences. They both perform the same functions, and they both talk to the same WebAccess Agent(s). The WebPublisher Application is used strictly for GroupWise Document Management access through a web interface. It does not retrieve users' mail, appointments, tasks, and so on.

Before discussing the next few components of the WebAccess gateway, let's take a look at what these additional objects are actually called:

  • GroupWiseWebAccess object

  • GroupWiseWebPublisher object

  • NovellSpeller object

  • GroupWiseDocumentProvider object

  • GroupWiseProvider object

  • LDAPProvider object

These six objects exist exclusively in the eDirectory tree and can therefore not be found in the GroupWise view. These objects are located in the context specified during the install of the WebAccess Application or WebPublisher Application. (Remember that this context might be under the GroupWise eDirectory domain object. They are not necessarily associated with a domain and do not exist in the WPDOMAIN.DB databases.) These objects are used to configure and administer the GroupWise Application pieces of WebAccess. Because GroupWise 7 offers many more features in WebAccess than previous versions, these objects are used as a better way to manage these functions. Also, because GroupWise WebAccess allows you to service multiple WebAccess Agents from a single WebAccess Application install, there has to be a way to manage just the WebAccess Application pieces of the picture. Having said that, the following discussion of the GroupWise WebAccess objects will help you understand how these all relate to the big picture of WebAccess.

GroupWise WebAccess Object

The GroupWise WebAccess object is the main component of the WebAccess Application. You can think of this object as being the WebAccess Application object that loads as a servlet on the web server. Through this object, you configure many of the settings that will affect the user's connection to WebAccess. This is the object that allows you to configure how a user interacts with the WebAccess gateway. Feel free to pull up the properties of your own GroupWise WebAccess object in your eDirectory tree and follow along.

To find the GroupWise WebAccess object, go into your eDirectory tree and highlight the GroupWise domain that you installed GroupWise WebAccess to. Figure 11.15 shows the location of the GroupWise WebAccess object in the wwwidgets system. The GroupWise WebAccess subcomponents discussed in this section are not available from the GroupWise view in ConsoleOne.

Figure 11.15. Locating the WebAccess Application objects

[View full size image]

When you edit the GroupWise WebAccess object, you can configure the following options.

Application/Environment Property Page

From the Application/Environment property page it is possible to define some of the basic environment settings for the WebAccess Application object. These are the settings beneath this page are:

  • Configuration File: This is the path to the WEBACC.CFG file. The WEBACC.CFG file contains all the configuration information regarding the GroupWise WebAccess object. This is a text file that can be viewed from any text editor. You can manually edit this file; however, it's kind of an all-or-nothing prospect. If you do edit the WEBACC.CFG manually, the changes you make are not written to eDirectory. But then when you try to edit the WebAccess Application from the ConsoleOne snap-ins, sometimes the snap-ins get confused and the WEBACC.CFG is configured incorrectly. On a NetWare server the WEBACC.CFG file is typically off of the SYS: volume in the Novell\WebAccess directory. On a Linux server it is typically at the path /opt/novell/groupwise/webaccess.

  • File Upload Path: This is the path to which attachments are uploaded to the web server when a user attaches a file to a newly composed email from WebAccess. As soon as the user clicks OK to attach a file, WebAccess begins uploading it to this directory. This allows the upload to be taking place in the background so that the user can continue to compose the mail message. After the message is sent or cancelled, the uploaded file is deleted from this upload directory.

  • Logout URL: Here you can enter an URL that a user will be sent to when logging out of the WebAccess client. You can enter any URL here, and the user's browser will be directed there upon logging out. This is very handy if you want to send the user to a particular website upon exiting.

Together, these three settings allow you to configure the paths employed by the WebAccess Application object.

Application/Log Settings Property Page

The Application/Log Settings property page is where you can configure the log settings for the WebAccess Application. Rarely will you need to access the Application's log files. It's the WebAccess Agent's log files that are generally of interest.

Application/Services Property Page

The Application/Services property page is where you can define which services are available through the WebAccess Application by listing what are called GroupWise providers. These providers are discussed in just a bit. For now, think of this tab as providing the ability to configure whether the WebAccess Application can access either a WebAccess Agent or an LDAP server. The reason for the LDAP server portion is that, from the WebAccess address book, you can query other LDAP servers to look up names and addresses in their directories. Without the LDAP provider defined as an active service on the GroupWise WebAccess object, LDAP lookups from the WebAccess client address book would fail. Similarly, if you did not have the GroupWise provider listed here as an active service, the application could not physically talk to a GroupWise agent.

Note

You cannot have multiple instances of the same provider listed here. If you choose to edit a listed provider, it takes you to the properties of that particular provider, which you will read about shortly. Deleting a listed provider does not actually delete the provider from the system, but simply deletes it from the GroupWise WebAccess object so that this service is not active from the GroupWise WebAccess object's point of view.

Application/Templates Property Page

The Application/Templates property page is where you can define the type of interface users see when accessing WebAccess. It might be helpful for you to understand what templates are first. Figure 11.16 shows the Application/Templates Property Page.

Figure 11.16. The Application/Templates property page

[View full size image]

You can think of templates as being containers that hold or display the data retrieved from a user's mailbox located at the post office. Templates are associated with the type of browser or device being used to access WebAccess. For example, if you were to access your GroupWise mailbox from a standard PC-based web browser such as Internet Explorer or Netscape, you would be using the standard HTML templates to view the contents of your mailbox. If you were to access your mailbox from a Pocket PC device running a browser, you would probably want to use a different set of templates, called simple HTML templates. Or if you were to access your mailbox from a wireless cellular phone, you would need to view your mail by using a different set of templates called WML (wireless markup language) templates. Templates are explained much more in Chapter 24, "Configuring GroupWise Wireless." Just remember that templates are the key to how flexible the GroupWise WebAccess system is as far as supporting and displaying the contents of a user's mailbox across many types of devices. For now, this chapter discusses some of the basic configuration options available for the WebAccess Application:

  • Template Path: This defines where all the template directories exist. If you were to look in the directory defined here, you would see several subdirectories under these, one representing each set of templates that WebAccess supports.

  • Java Package: A Java package name is a directory path that uses a period (.) instead of a slash (\) to separate components of the path. This path identifies the location of the template string tables. Unless you are an HTML developer and are creating your own custom templates, you will not need to modify this path.

  • Images URL: This is the path under the web server's document root directory where the images that you see from the WebAccess client are located. These images are *.GIF files; they make up the icons and buttons you see from the browser.

  • Applets URL: This identifies the path to the WebAccess applets. This should be blank unless you have moved the applets to a different server. You would then enter the path to another root directory. The default location of applets is under the web server's document root directory.

  • Help URL: This is the path under the web server's document root directory where the help HTML files are located. If WebAccess users want t o pull up the online help, they are directed to the INDEX.HTM file.

Tip

Under this help directory, there is a subdirectory that represents the language that the user is using. For example, if the language is English, you will see an EN directory under the HELP directory, which would contain the INDEX.HTM. You could then create your own help files, if desired.

  • Enable Template Caching: This option allows the WebAccess Application to cache the templates in RAM the first time they are used. This increases performance. Keep these settings intact.

  • Cache Size: This value determines how much RAM the web server will use to cache the templates. You can increase the template caching to 4000KB, which is our preference. Setting the cache beyond that is probably just a waste of memory.

  • Default Language: This identifies the default language that will be presented to users when they reach your web server's home page and you have selected to use the default WebAccess home page.

  • Define User Interfaces: Clicking this button allows you to set up custom user interfaces. This is useful when your users are using different types of devices to access their mailboxes. You can learn more about this in Chapter 24.

Application/Security Property Page

Some of the basic configuration options available beneath the Application/Security property page are discussed here:

  • Timeout for Inactive Sessions: This setting allows you to configure how many minutes of inactivity must pass before a user becomes disconnected from the application. The WebAccess Application does not tie up too many resources maintaining a WebAccess client session. We suggest changing the timeout to 60 minutes.

  • Path for Inactive Sessions: Imagine that you are in the middle of composing an email from the WebAccess client and are interrupted for several minutes. The inactive session timeout value kicks in, and you get disconnected. The WebAccess Application saves your session before disconnecting. When you come back and reauthenticate to WebAccess, you can resume your email.

  • Use Client IP in Securing Sessions: If this option is checked, the WebAccess Application uses the client's IP address to help construct the hash value used to identify the user's browser session within the WebAccess Application. Be aware, however, that if a user's browser is configured to use a proxy server, there is a chance that the proxy server can use different IP addresses during the same session. This would cause invalid hash errors to appear on the WebAccess Application. If you see this type of problem, you will want to disable this option. The GroupWise WebAccess Application handles session security through the use of cookies. The only reason you would need to check this option is if users access GroupWise WebAccess through a browser that does not accept cookies.

Warning

AOL users usually have difficulties using GroupWise WebAccess if you enabled Use Client IP in Securing Sessions. The AOL client relies heavily on proxy servers, so a user's session with the WebAccess Application can change often as the proxy server's IP address changes.

Application/Settings Property Page

The Application/Settings property page, shown in Figure 11.17, is where you enable or disable options that users will see from the WebAccess client. If you disable an option, that particular option's interface will be missing for all WebAccess users accessing this particular WebAccess Application.

Figure 11.17. The Application/Settings property page, where options such as the LDAP directory search has been disabled

[View full size image]

The available settings on this page are listed here:

  • Spell Check Items: Here you can either enable or disable the user's ability to spell-check newly composed email messages before sending them.

  • Search LDAP Directories: If this option is disabled, users will not be able to search the admin-defined LDAP servers for email addresses. If you do not have an LDAP address book for your users to search (most people don't), there's really no reason to have the LDAP address book capability show up in the WebAccess client address book. In the example shown in Figure 11.17, the LDAP directory search has been disabled. You can find more about setting up LDAP servers later, in the section "Configuring an LDAP Address Book for WebAccess."

  • Change Passwords: This option allows users to change their GroupWise master mailbox password from WebAccess. Be aware that if LDAP is enabled and you are using Novell's eDirectory as your LDAP server, when users change their password here, they are changing their eDirectory password also. This is really slick when you think of it. Conceivably, your users can change their eDirectory authentication from their WAP-enabled cell phones.

  • Access Document Management: This option controls user access to documents from within GroupWise libraries. Some organizations want users to access document management only from a GroupWise 32-bit client. This is the case at WorldWide Widgets. In the sample Settings page shown in Figure 11.17, the capability to view documents from WebAccess is disabled.

  • Open Attachments in Native Format: This setting governs whether users can open attachments from their browsers. Their web browser needs to be able to determine the file type, and then launch the document into the associated application. Some browsers do a better job of this than other browsers. We recommend checking this option.

  • Open Documents in Native Format: This option has to do with GroupWise document management. Most customers, even those using document management, will want to disable this check box. Opening a document from document management in the WebAccess client can cause version-control issues.

  • Include Only Files with These Extensions: By filling in this field, you can specify just what kinds of files users have an option to open. The users can always save the file to their own computer and try to open it there.

  • View Attachments in HTML Format: This option is useful if you do not want to give users the ability to view attachments from within WebAccess. It removes the view option from mail with attachments when they read them. You can allow users to open the attachments in their native applications, though. Personally we think it is a good thing to allow users to view attachments in HTML format, but not all attachment types.

    Fortunately, there's a place where you can exclude certain document types; read on.

  • View Documents in HTML Format: This option performs the same functionality as the preceding function. If you disable this option yet document management is enabled, users can view the document in HTML format.

  • Exclude Files with These Extensions: This setting allows you to exclude files such as *.PDF files (which are better viewed from Acrobat reader) from HTML viewing.

  • Customize Settings in XML: This button launches an XML editor that can be used to modify the settings on the WebAccess Application. There are several settings you can enable or disable through this interface. For example, if you want to disable the calendar functions from a WebAccess Application, you can do so from this interface. Or you might want to set a limit on the size of attachments that are viewable through the WebAccess Application. You can do this by changing the Document.View.maxSize setting. The default value is 1MB. We like this setting; however, if you want to increase this setting beyond 1MB, you can. If a file exceeds the Document.View.maxSize setting, the users cannot view the document, but they can save the file and then launch it in the native application.

NovellSpeller Object

The NovellSpeller object basically represents the GroupWise speller servlet object. It is created when you install the WebAccess Application object. The speller servlet object automatically starts when the web server loads the WebAccess Application.

Application/Log Settings Property Page

From the Application/Log Settings property page, you can configure the log settings for the speller. Rarely will you need to look at the speller's log files.

Application/Environment Property Page

The settings here are really the only thing you can configure on the speller object, other than the logging. The settings available are listed here:

  • Configuration File: This is the path to the spell checker's configuration file. It is a text file that contains all the configuration information regarding the spell checker.

  • Dictionary Path: This is the path to the dictionary files that contain the word lists and suggestions used during spell checking.

  • Maximum Suggestions: Here you can enter the maximum number of suggestions to give when a misspelled word is encountered during a spell check.

  • Customize Settings in XML: Here you can also modify these settings from the included XML configuration editor.

Those are all the settings available for the speller object. Most customers will not need to make any changes to the speller object.

GroupWiseProvider Object

The GroupWiseProvider object works in conjunction with the GroupWise WebAccess object or the WebAccess Application. Think of it as the actual transport provider that is responsible for carrying the data between the WebAccess Agent and the WebAccess Application. This might sound a bit confusing because the entire chapter notes that the GroupWise WebAccess Application talks directly to the WebAccess Agent. Basically it does, but for administration purposes and future support for additional features in WebAccess, it has been broken into providers.

A user's web browser talks to a servlet running on the web server. This servlet functions as the default WebAccess Application. The Application then looks up which providers it has access to and hands the request over to the appropriate provider. This all happens on the same server. There is not an actual separate program that acts as the provider; it is all bundled into the WebAccess Application, but it acts as a separate, configurable subprocess of the WebAccess Application. The provider then communicates directly to the agent. If you think of it this way, it will be much easier to understand how the provider objects relate to the WebAccess Application or servlets.

Configuring the GroupWiseProvider object is really quite simple and straightforward. The following properties of the GroupWiseProvider object can be configured:

  • Timeout for Busy Search: This value sets the number of minutes the provider waits when performing a busy search to the WebAccess Agent. This allows the administrator to control how soon busy searches are cancelled through the WebAccess client.

Note

A busy search is a feature that allows you to check when other GroupWise users are available so that you can schedule an appointment with them through the GroupWise calendar.

  • Configuration File: This simply points to the COMMGR.CFG file that the provider uses to determine where the WebAccess Agent is (the IP address and port) and how to encrypt the data in transit using the encryption key embedded in the COMMGR.CFG file.

  • GroupWise WebAccess Agents: This is where you list all the WebAccess Agents that the provider will be able to communicate with. You must have at least one agent defined here, but you can have multiple agents. This gives you a level of fault tolerance in regard to the WebAccess Agent.

The GroupWiseProvider object is most useful when used for the fault-tolerance capabilities of WebAccess.

LDAPProvider Object

The LDAPProvider object basically serves the same function as the GroupWiseProvider object; the WebAccess Application sends requests for LDAP lookups to it, and then the LDAP provider looks up and hands the results back to the GroupWise WebAccess object. The LDAPProvider object does not communicate with the WebAccess Agent like the GroupWiseProvider object does. Instead, it queries whatever LDAP servers have been configured for lookups directly.

Following is an explanation of the settings you can configure on the LDAPProvider object:

  • Configuration File: This setting points to the path of the LDAP configuration file. This is a text file that contains all the configuration information for the LDAP provider. This file contains the settings for the LDAP servers, for example.

  • LDAP Servers: This setting lists the configured LDAP servers that would be available to search from the WebAccess client. In the upcoming section "Configuring an LDAP Address Book for WebAccess," you learn how to set up additional LDAP services.

  • Customize Settings in XML: Once again, you can configure these settings from the XML configuration editor, if desired.


Configuring the Document Viewer Agent

The documents that users attach to email messages are as varied as the combinations of document formats, tools, and users throughout the world. To display documents in your web browser, WebAccess must convert them to HTML. Because some documents contain totally unexpected data, WebAccess cannot convert them. In the past, in some cases, the WebAccess Agent would hang when it could not convert a document. If this occurs, the activities of all WebAccess users is interrupted.

In GroupWise 7 the new Document Viewer Agent resolves the problem by taking over the document conversion task from the WebAccess Agent, which processed these attachments itself in previous versions. The Viewer Agent, shown in Figure 11.18, can process multiple documents simultaneously. If it encounters a problem with a document, the problem does not affect its processing of other documents, nor does it affect the functioning of the WebAccess Agent. Therefore, WebAccess users no longer experience interruptions because of documents that fail to convert into HTML.

Figure 11.18. The WebAccess Document Viewer Agent console screen on NetWare offers a great overview of all the conversion tasks

[View full size image]

The Viewer Agent is automatically installed along with the WebAccess Agent, and the WebAccess Agent manages the Viewer Agent, starting and stopping it as needed. The default configuration of the Viewer Agent is sufficient to provide basic document conversion functionality. Additional functionality can be enabled using startup switches in the Viewer Agent startup file (gwdva.dva). The startup file lists all available switches. The most helpful switches are described here:

  • Viewer Agent Web Console: As with the other GroupWise agents, you can view configuration and status information about the Viewer Agent in your web browser. To enable the Viewer Agent web console, add the /http startup switch to the Viewer Agent startup file. The default port number is 7439. Use the following URL to display the Viewer Agent Web console:

    http://server_address:7439

  • Document Quarantine: You can configure the Viewer Agent to quarantine documents that cannot be converted to HTML so that they can be examined manually if necessary. To enable the file quarantine feature, add the /hold startup switch to the Viewer Agent startup file. Documents that fail HTML conversion are then placed in the hold subdirectory that is created wherever the Viewer Agent program has been installed.

  • Document Cache: You can configure the Viewer Agent to cache documents that have already been converted to HTML. This speeds up document display when the same document is viewed multiple times and by multiple users. To enable document caching, add the /cache startup switch to the Viewer Agent startup file. This creates a cache subdirectory wherever the Viewer Agent program has been installed. Under the cache subdirectory, converted GroupWise library documents are stored in a library cache subdirectory and converted document attachments are stored in a transient cache subdirectory.

The configuration file for the Viewer Agent is calledGWDVA.DVA and the temporary files are stored in a directory called GWDVA.DIR; on NetWare both are located in the SYS:SYSTEM directory by default. The configuration file contains settings for the number of threads, logging options, HTTP parameters, file caching parameters, and quarantine; perhaps one of the most interesting is the option to specify a recipient for notifications of attachments that have been put in the quarantine. All of these settings are currently not configurable via ConsoleOne. It is expected that these parameters will be added to ConsoleOne in a future release.

On NetWare and Windows, the Viewer Agent has the same type of user interface as the WebAccess Agent. On Linux, the Viewer Agent runs only as a daemon with no user interface. You can monitor the Linux-based Viewer Agent activity by viewing its log file. Change to the Viewer Agent log file directory, and then display the end of the current log file using the following commands:

cd /var/log/novell/groupwise/gwdva
tail -f mmdddva.nnn

Here, mmdd is the month and date (for example, 0318) and nnn is an incrementing extension (for example, 001 for the first log file of the day). The -f option keeps the file open and follows additions to the file so that additions to the log file appear on the screen as they occur.

You should now be comfortable configuring most of the aspects of the WebAccess gateway, including the WebAccess Agent and Application. In future sections, you'll learn how to leverage these settings to create a highly reliable, and scalable, GroupWise WebAccess gateway for your environment.


Understanding the GroupWise WebAccess Console

This section discusses the options shown when you view the WebAccess console. Each statistic is discussed to help you understand the status of the WebAccess Agent. Following is an explanation of the interface of the GroupWise WebAccess Agent running on the NetWare platform:

  • Threads: Here are some of the most valuable statistics you can gather from the WebAccess Agent. There are three thread values here. The Busy value represents how many WebAccess threads are currently in use. The Total value represents how many total threads are available to service requests. This is the maximum number of threads available. The Peak value represents the maximum number of concurrent threads that have been active at the same time.

  • Users In: There are three values here as well. The Current value lists the number of currently logged-in users at this moment in time. The Total value is the total number of users who have logged in since the agent has been up. (Up time is indicated in the upper-right corner of the WebAccess Agent.) The Peak value represents the maximum number of users logged in at the same time.

  • Requests: There are two statistics here. The Total value represents how many requests have come into the WebAccess Agent since it has been up. The Errors value shows how many errors have occurred since the agent has been up. You can view the log files to determine which errors occurred. In the upcoming section "Monitoring GroupWise WebAccess Through a Web Browser," you will learn how to search these log files.

  • Logging Box: This is the window directly under the Statistics window, and it displays the activity on the WebAccess Agent. The far-left value represents the thread number that is performing the task. Next is the time the event occurred, and last is the information associated with the particular request being logged. The logging level determines how much information is displayed here.

  • F9 = Browse Logfile: Pressing F9 from the agent console screen brings up a static copy of the current log file. Notice that at the beginning of each log file is the basic configuration information of the agent. It might be helpful information to verify which settings the agent is using.

  • F10 = Options: Pressing F10 brings up a dialog box with two options: View Log Files and Logging Options. If you select to view log files here, you are given a list of all the log files that the WebAccess Agent has created over a period of time. You can select any of the log files and view their contents. If you select Logging Options, you can change the current log settings that the agent is using. These log settings are discussed further in the upcoming section "Understanding the GroupWise WebAccess Log Files."

Tip

When you change these log settings here, they are active only while the WebAccess Agent is up and running. When the WebAccess Agent is restarted, it will pick up the log settings from either the startup file or the setting defined through the properties of the WebAccess Agent object in ConsoleOne.

If you are running the WebAccess Agent on Windows 2000/2003, the console screen is different. You do have some function keys that help control the console screen from within Windows. Here are the commands you can issue from the console when running the agent on Windows 2000/2003/200x (note that these commands are not available when running the agent as a service):

  • F1 or F7: Pressing F1 or F7 from the agent screen exits the WebAccess Agent.

  • F2: Pressing F2 cycles the log level on the WebAccess Agent. The available levels are normal (default), verbose, and diagnostic. Normal is usually adequate unless you are troubleshooting a particular problem with the agent and need additional logging information.

    Tip

    The log level set via F2 is active only as long as the WebAccess Agent is up. If it is restarted, the log level is set to the option defined in either the startup file or the WPDOMAIN.DB file through ConsoleOne.

  • F12: Pressing F12 displays the statistics and thread activity of the agent. This is the same thread information you get from the agent when it is running on NetWare as an NLM. The values mean the same thing. It also gives the current log level, tells whether disk logging is enabled, and indicates the name of the current log file.

As you can see, there are not a lot of different statistics or configuration pieces to the WebAccess Agent compared to some of the other agents or gateways.


Understanding the GroupWise WebAccess Log Files

This section explains how to access and understand the different log files generated by the components that make up the WebAccess gateway. Generated log files can be invaluable in troubleshooting and resolving problems with any GroupWise component, not just WebAccess. The log files are generated by the following pieces of the GroupWise WebAccess gateway:

  • WebAccess Agent

  • WebAccess Application

  • WebAccess speller application

  • WebPublisher application

To begin with, here's a definition of some of the standard logging settings that most of the components in WebAccess share:

  • Log File Path: This defines the path where the log files will be located for a particular Agent or Application. For the WebAccess Agent it is important that you specify a location for the log file in ConsoleOne. If you do not do so, the WebAccess Agent will write to a log file.

  • Logging Level: This setting defines the logging level for the Agent or Application. The valid settings are generally normal (default), verbose, diagnostic, and off. The higher the level of logging, the more detailed the log files will be. Diagnostic logging should be used only when you're troubleshooting a problem and you need very detailed information as to what is happening at the particular agent or application level. You should not run diagnostic logging as a standard practice. Normal or verbose will suffice. We prefer verbose logging on the WebAccess Agent.

  • Max Log File Age: This setting allows you to set the number of days that log files will be kept. If, say, this is set to seven days (the default), when a log file reaches an age of seven days, the Agent or Application will automatically delete this log file. We like to increase this setting to around 30 days if possible, because you never know when you might need to dig back through a few weeks' worth of log files to help track down and troubleshoot problems.

  • Max Log Disk Space: This setting determines how much disk space all the log files for a particular Agent or Application can consume. It is not how large a single log file can be. All the individual log files will be 256KB in size, and then the Agent or Application will cycle into another log file. As mentioned, this setting allows you to control how much disk space the log files use. We like to increase this setting. It depends on your environment as to how large you set this value. We have seen systems on which 10MB worth of logs would keep only a couple of days' worth of data because of the volume of information being generated. You will want to take a baseline of your system to see which value works best for your environment.

Therefore, whatever setting is reached firstbe it the max log file age or the max log disk space settingwill take precedence over the other. Having these two settings together allows you to completely control how many and how long the log files stick around for your WebAccess processes. Now that you understand some of the shared characteristics of logging on the WebAccess processes, the following discussion points out the differences between the different processes.

WebAccess Agent Log Settings

By default, the WebAccess Agent does not generate a log file to disk. You must enable this option by adding the /logdiskon switch to the STRTWEB.NCF file, or by defining a path to the log files on the WebAccess Agent object. This will enable disk logging for the WebAccess Agent. Without this switch or a defined path to the log files, the WebAccess Agent will not log any events to disk. The default location of the WebAccess Agent log files is the DOMAIN\WPGATE\WEBACCESS\000.PRC directory, but you can change this with the log file path setting on the agent.

There are also startup switches that allow you to set all the logging options from the command line when the agent is loaded. These switches are contained in the Agent startup file. You can modify the following switches:

  • /log=: Indicates the path to the log files.

  • /logdiskon: Enables disk logging.

  • /loglevel=: Sets the log level. Values are normal, verbose, and diagnostic.

  • /logdays=: Sets the number of days to keep logs. Enter a number that represents days.

  • /logmax=: Sets the size of log files. Enter a size in kilobytes.

Even with all the possibilities, we still recommend that you configure these settings from ConsoleOne, and not from the startup file of the WebAccess Agent.

GroupWise WebAccess Object Log Settings

The GroupWise WebAccess object log settings, or in other words the WebAccess Application settings, are configured by going to the properties of the GroupWise WebAccess object and selecting Application/Log Settings.

Notice that here you have a few additional options besides the standard settings:

  • Log Language: This allows you to define the language that the log files are written in.

  • Log Time Format: This allows you to change the format of the time value displayed in the log file. The default is H:mm:ss for Hour:Minute:Second. If desired, you can change this order. You have the option of adding MM/dd or dd/MM for Month/Day or Day/Month to the logging, which might be useful.

Tip

The name of each WebAccess Application log file will be in the format of MMDDWAS.XXX, in which XXX is an incremented number throughout a 24-hour period. The agent always cycles to a new log at 24:00 hours.

WebAccess Speller Application

Configuring the speller log settings is similar to configuring the agent and application log settings. This can be done by going to the properties of the NovellSpeller object in eDirectory. For this agent, you do not have the options of setting the max log disk space and max log file age, however.

WebAccess WebPublisher Application

The WebAccess WebPublisher log settings are exactly the same as the GroupWise WebAccess object settings.


Configuring an LDAP Address Book for WebAccess

This section explains how to configure an LDAP address book. From the address book, the user can perform LDAP lookups on predefined LDAP servers. As an administrator, you have the flexibility of defining additional LDAP servers, thus allowing users to query LDAP-compliant servers for addresses. The GroupWise Windows 32-bit client gives users the ability to define LDAP address books, so this functionality has also been added to the GroupWise WebAccess client. By default, two LDAP servers are created when the WebAccess Application is installed. They are the popular public LDAP servers BigFoot and SwitchBoard.

You configure additional LDAP servers through the LDAPProvider object. This object was created when the WebAccess Application was installed.

Here you will see the two default LDAP servers. You are presented with a configuration screen that allows you to set up the new LDAP server. When you click the Edit or Add buttons, you'll see the following options:

  • Name: Enter the name of the LDAP server. This is the name that the user will see when selecting an LDAP server to search from the WebAccess client.

  • Server: Enter the DNS name or IP address of the server that is servicing LDAP requests from clients.

  • Port: The standard LDAP port is 389. If the LDAP server you are defining has been configured to use a different port, you should modify this field. If not, keep the default port.

  • Maximum Results: Enter the maximum number of results that can be returned to the WebAccess client from the LDAP server. The default is 100.

  • Timeout: The timeout value here represents how long the LDAP provider will wait on the configured LDAP server for a reply. The default is 30 seconds

  • Search Base: Enter the search base value here. LDAP servers allow you to configure a search base that sets limits on how many objects can be searched. When the LDAP server was set up, a search base should have been defined. This search base should match the search base defined on the LDAP server.

  • Image URL: This is the path to the image file that you would like displayed to represent the particular LDAP server you are defining. This path must be defined off the root of the web server's DOCS directory.

  • Web URL: This is where users are sent if they click on the image defined in the Image URL value. This is a nice way to link a website to the LDAP server graphic.

  • Username: Enter the LDAP username that must be used to authenticate to the LDAP server you are defining. Some LDAP servers do not require authentication.

  • Password: Enter the LDAP username's password here. This allows the LDAPProvider object to authenticate to the LDAP server and perform the query, if necessary.

  • Define Field Mappings: Click this option to set up field mappings. If your LDAP server is configured to return additional values for each user, you can map these fields to fields that will be displayed in the WebAccess client.

    If you need to add additional field mappings, click Add. This will add a row where you can then type in the LDAP and local fields.

This section covered how to create additional LDAP address books that are then available within the GroupWise WebAccess address book.


Monitoring GroupWise WebAccess Through a Web Browser

This section discusses the options for monitoring your WebAccess system through any standard PC-based web browser. It discusses how to monitor both the WebAccess Agent and the WebAccess Application.

Monitoring the Agent from a Web Browser

To have this functionality, the WebAccess Agent must be enabled to allow HTTP monitoring. This can be done during the install, with startup switches, or by modifying the WebAccess Agent object from ConsoleOne (which is our preference).

After you have the HTTP monitoring enabled for a WebAccess Agent, you can browse to the agent using a web browser and the following syntax:

http://server IP or DNS address:http port

Here's an example: http://groupwise.wwwidgets.com:7211.

You will be prompted with the HTTP username and password that you configured for the GroupWise WebAccess Agent. Figure 11.19 shows a WebAccess Agent that is being monitored from a web browser.

Figure 11.19. Monitoring GroupWise WebAccess through a web browser

[View full size image]

Here's an explanation of some of the information shown in Figure 11.19:

  • Status: The status page shows you the current status of the WebAccess Agent. Here you can get a good idea of how the WebAccess Agent is performing. Notice under the Statistics section that you can view how much memory the server has, as well as the current processor utilization of the server.

    Note

    If the agent is running on a Windows 2000/2003 server, you do not get the processor utilization reading.

  • Configuration: The configuration tab shows you the current configuration of the WebAccess Agent. This is helpful if you need to check how the WebAccess Agent is configured. You can quickly check all configuration settings here.

  • Environment: The Environment tab shows you different options depending on which platform your agent is running onNetWare versus Windows. The NetWare Environment tab shows you the following information as regards the server configuration:

    Server

    WWWFS1

    Company

    Novell

    O.S. Revision

    NetWare 5.60.02

    O.S. Date

    July 10, 2002

    Memory

    614015

    Processor utilization

    5%

    Supported connections

    31

    Connections in use

    1

    Clib version

    5.6

    Receive buffer max

    5000

    It also shows all loaded modules on the NetWare server.

  • Log Files: The Log Files tab allows you to view the contents of the WebAccess log files. You will see a list of all agent log files. You can highlight any one and select View Log to see the entire contents of that particular log file. If disk logging is not enabled, you cannot view any logs, because there aren't any.

This section covered how to configure HTTP monitoring of the GroupWise WebAccess Agent. The next section explains how to configure HTTP monitoring of the WebAccess Application.

Monitoring the Application from a Web Browser

By default, the Application does not have HTTP monitoring enabled, so you must manually enable this service. This is accomplished by performing the following steps:

1.
Edit the WEBACC.CFG file. On a NetWare server this file is typically found in the SYS:\NOVELL\WEBACCESS directory. On a Linux server, this file is typically found at /opt/novell/groupwise/webaccess. Be sure to keep the case of the file lowercase on the Linux platform.

Note

You might see several WEBACC.CFG.X files in this directory as well. These are backup copies of the WEBACC.CFG file. You are interested in the WEBACC.CFG file, because this is the file that the Application reads for its configuration information.

2.
Identify the following section of this file:

#Application Administration Tool
# Invoked on the URL
# (e.g. http://<server>/gw/webacc?action=Admin.Open)
#########################################################
Admin.WebConsole.enable=false
Admin.WebConsole.username=admin
Admin.WebConsole.password=admin

3.
Change the line that reads

Admin.WebConsole.enable=false

to this:

Admin.WebConsole.enable=true.

4.
Change the username from admin to a username of your choosing in the Admin. WebConsole.username= field. This is not an eDirectory or a GroupWise user ID, and it is strictly used for monitoring the WebAccess Application.

5.
Change the password from admin to a unique password in the Admin.WebConsole.password= field. This password should be very secure. Make it at least eight characters long, and include numbers, punctuation marks, and letters. The reason for using such a hard-to-guess password is that there is no intruder detection here, and anyone can access the /gw/webacc page of your WebAccess system if they guess the username and password. So in the interest of security, change the default user and password values from admin to something you are comfortable with.

6.
Shut down the WebAccess Application and restart it.

Tip

If you are running the Application on NetWare 6 or newer with the Tomcat33 or Tomcat4 servlet engine, you can simply issue the following commands on the NetWare server console:

java killall
java exit
tomcat33 or Tomcat4

This will shut down just the servlet engine and then restart it.

On the Linux platform the command will typically be this:

/var/opt/novell/tomcat4/bin/catalina.sh stop
/var/opt/novell/tomcat4/bin/catalina.sh start

7.
Now you are ready to access the HTTP interface of your Application. You do this by using the following URL:

http://gw/webacc?action=Admin.Open

Notice that all you need to do is access the sign-in page of your WebAccess server, which places you at yourserversDNSName/gw/webacc. You then add ?action=Admin.Open to the end of your URL.

8.
You are then prompted for the username and password that you defined in the WEBACC.CFG file in steps 4 and 5. Enter this information, and you will then access the HTTP monitoring of the WebAccess Application. Figure 11.20 shows what you might see.

Figure 11.20. Monitoring GroupWise WebAccess Application through a web browser

[View full size image]

Here's an explanation of some of the information shown in Figure 11.20:

  • Status: The status page will display information about all users who have logged into WebAccess from this particular Application. You can see the date and time that the user logged in, as well as the last time the user communicated with the Application. This can be helpful to identify users who use WebAccess the most, and stay connected for long periods. You can also see the client IP address of the user's browser, the user's UserID.PostOffice.Domain, and the WebAccess Agent version that is currently servicing this user. You can also see which browser the user is using to access WebAccess. This can be great to identify users who are using PDAs or WAP devices. It can also be used to identify any new browsers. You can also sort on any of these columns. This is great if you want to see all the users who are accessing a particular agent, or to see who has logged in the most.

    If you click on a user who is logged in, you will be taken to a page that will display detailed information about this user. You can see which templates the user is using, the language the user is running in, as well as the list of WebAccess Agents that the Application can fail over to for this particular user. You can easily see exactly which agent the user is currently talking to, and which agent the user will fail over to in case the current agent has a problem. The * in the Using column indicates which Agent the user is currently communicating with. Figure 11.21 shows an example of this.

    Figure 11.21. Viewing a user through the WebAccess Application monitor

    [View full size image]

  • Configuration: The Configuration tab displays information about the version of Application you are running, and how the Application is currently configured. You get Java vendor information on your Java servlet as well. You can also view all the Application's configuration files in a read-only mode. This is great if you need to quickly see how something is configured.

  • Log Files: The Log Files link allows you to view the logs of the WebAccess Application. This is very useful to see which agents the Application could not communicate with, or other errors that occurred at the Application.

There you have it; you now have several excellent tools to monitor the current state of your WebAccess system.


Advanced Installation Options for WebAccess

This section discusses some of the more complex and advanced installation options in WebAccess. These might not apply to your environment, but they should be useful for many of the GroupWise administrators out there.

Chapter 31, "Creating a Highly Available GroupWise WebAccess Solution," has some advanced design considerations you should consider for your GroupWise WebAccess environment.


Changing the GroupWise WebAccess Login Experience

This section talks about what the user sees and experiences before actually seeing the mailbox from the WebAccess client. This section also covers the options for accessing WebAccess by entering additional information on WebAccess' URL line.

To begin with, there are many ways you can design access into a user's mailbox through WebAccess. Here is a list of the more common approaches we've seen:

  • You can have the user simply enter a URL into a browser to access the language page for WebAccess. Here, the user selects the language and then is prompted for a GroupWise username and password.

  • You can skip the language page altogether and send the user directly to the username and password page.

  • You can configure your WebAccess system so that users must enter a generic username and password to get to the username and password screen of WebAccess. This might help deter would-be hackers from trying to guess GroupWise usernames and passwords.

  • You can send users to a company welcome page with FAQs and information about WebAccess on it. From here, users would click some sort of link to get to the WebAccess username and password screen.

As you can imagine, there are many ways to determine what users see before they actually get to their mailboxes. The important thing to remember is that the last thing users must see in order to access their mailboxes from WebAccess is the login page. This is where they will enter their GroupWise usernames and passwords. To get to this login page, the user must get to the following type of URL:

http(s)://your web server DNS Name/gw/webacc

After users get here, they enter their user IDs and passwords and are logged into their GroupWise accounts.

The following URL provides some additional information to help determine how to set up access into users' mailboxes through WebAccess:

http://your web server DNS
Name/gw/webacc?GWAP.ip=10.1.1.1&GWAP.port=7205&User.lang=en

This URL directs the browser to use a specific agent located at the IP address 10.1.1.1 using port 7205, and to specify English as the language.

The following URL forces the WebAccess Application to use the simple HTML templates to deliver the content to the browser:

http://your web server DNS Name/gw/webacc?User.interface=Simple

This can be helpful for testing purposes. If users were using a very slow link, you might want to add this as a link from a main page. WebAccess is a bit quicker when the simple templates are used compared to the default frames.

You will see that after the /gw/webacc you must begin the operands with a ? (question mark). Then you separate each operand with an & (ampersand). Knowing this, you can string together something like the following:

http://your web server DNS
Name/gw/webacc?GWAP.ip=10.1.1.1&GWAP.port=7205&User.lang=en&User.interface=Simple

This URL should be all one line; it is broken up so that it fits on the printed page.

Note

These URL examples are case sensitive. You cannot enter user.lang or user.interface=simple and have the URL work.


Skipping the GroupWise WebAccess Language Page

When you install the WebAccess Application and replace the existing default web page, you are prompted to select your language when you log in to WebAccess. In many cases, you might want to simply skip this language page and send users directly to the login page.

If you are planning on setting up a web page that gives users a jumping-off point before they get to the login page, it is very simple to skip the language page. For example, say you want the users to get a welcome HTML page that includes company information or information about how to use the WebAccess system. You simply add a link to the default HTML page that points to the WebAccess Application running on your web server. When you define the link into WebAccess, it would look something like this:

http://your web server's DNS name/gw/webacc

Because you specified the actual servlet that WebAccess is using, you skip the language page. The users enter their usernames and passwords and are directed to the correct or default WebAccess Agent.


Disabling the GroupWise Document Management Options

Some organizations do not use the GroupWise Document Management features, and therefore would not like to show the Document Management tab in WebAccess. There is a way to remove this tab:

  1. In ConsoleOne, go to the GroupWiseWebAccess application object and open this object.

  2. Go to the Settings tab and you will see the option Access Document Management.

  3. Uncheck the check box and save the changes. After three minutes (or whatever value the Config.Update.check variable in webacc.cfg is set to), the Document Management tab will be gone.

There is no need to restart Tomcat.


Specifying WebAccess Client Themes

The GroupWise WebAccess client has the capability to support different color schemes called themes. You can change the default themes from within the WEBACC.CFG files. You accomplish this task by performing the following steps:

1.
Edit the WEBACC.CFG file. On a NetWare server this file is typically found in the SYS:\NOVELL\WEBACCESS directory. On a Linux server, this file is typically found at /opt/novell/groupwise/webaccess. Be sure to keep the case of the file lowercase on the Linux platform.

Note

You might see several WEBACC.CFG.X files in this directory as well. These are backup copies of the WEBACC.CFG file. You are interested in the WEBACC.CFG file, because this is the file that the Application reads for its configuration information.

2.
Identify the following section of this file:

## 1 - Sky Blue (default)
# 3 - Blue
# 4 - Olive Green
# 5 - Silver
# 6 - Spring Green
# 7 - Sterling Silver

Theme.index=1

3.
Modify the Theme.index line to indicate the theme color you would like. For example, for Spring Green the line should read like this:

Theme.index=6

4.
Save the changes to the webacc.cfg file.

5.
Shut down the WebAccess Application and restart it.

Tip

If you are running the Application on NetWare 6 or newer with the Tomcat33 or Tomcat4 servlet engine, you can simply issue the following commands on the NetWare server console:

java killall
java exit
tomcat33 or tomcat4

This will shut down just the servlet engine and then restart it.

On the Linux platform the command will typically be this:

/var/opt/novell/tomcat4/bin/catalina.sh stop
/var/opt/novell/tomcat4/bin/catalina.sh start

6.
Now when users access GroupWise WebAccess, the theme color will be Spring Green.

You have now changed the default theme.


Best Practices

In this section, we share some tips we have learned through trial and error that will help you better design or set up and maintain the WebAccess system:

  • Keep WebAccess Agents as close to users as possible. In other words, if you have a domain across a WAN link, it's best to install a WebAccess Agent under this domain, and then define this WebAccess Agent as the preferred agent for this domain.

  • Keep the agent on the same server as the GroupWise domain.

  • Configure your web server to support SSL. Chapter 27 explains how to do this for an Apache web server on the NetWare platform.

  • Monitor closely how heavily the WebAccess Agent is being used. You might need to increase the thread count to provide suitable performance for users.


Summary

This chapter discussed many of the aspects of the WebAccess system. After reading and studying this chapter, you should be able to successfully implement a simple WebAccess system. You will also be able to successfully monitor and identify how your WebAccess system is being used, and by whom. By understanding some of the underlying concepts related to how the WebAccess system works, you will also have the knowledge to provide solutions in your environment for users needing access to their GroupWise mailboxes from any web browser. Note that Chapter 24 and Chapter 31 closely tie to this chapter.


Chapter 12. Administering the GroupWise Client

With GroupWise 7, you can also use several types of client software, either from Novell or from other parties. One example is Evolution, the most popular email client on almost any Linux distribution. With GroupWise 7, Evolution can now connect natively to the post office agent (POA) using the new SOAP/XML interface in your POA. Another example is the Cross-Platform client for Linux and Apple, which offers a set of features similar to those of the Windows client. And last but not least, Novell has added a completely redesigned GroupWise Connector for Outlook, offering the option for any ordinary Outlook 2003 user to connect to the robust GroupWise back end instead of the old Exchange environment.

All these new possibilities are of course very interesting, but this chapter mainly focuses on the platform that is still used most: In the near future most users will still use the GroupWise Windows 32-bit client to connect to the GroupWise information store. Novell has realized this, and GroupWise 7 introduces some very significant changes to the Windows client, in look-and-feel, but also in regard to installing and administering this client. The Windows client provides access to the user mailbox; documents in libraries; and archive, caching, and remote mailboxes. It offers the user tools for creating rules, sharing folders and address books, and of course doing all of those things normally associated with email.

The GroupWise client also offers some tools that can be considered administrative, especially where document libraries are concerned. These include mass-change operations on documents. For that matter, any operation that makes use of a user's administrator-assigned manage right to a library is going to be performed from the GroupWise client.

This chapter covers administration of the GroupWise 32-bit Windows client. Specifically, this chapter looks at deploying and updating the client, and administering logins and client options.


Understanding the GroupWise Windows Client Installation Process

The GroupWise 7 client is installed from the GroupWise 7 Client CD or from the CLIENT\WIN32 folder of the GroupWise 7 Software Distribution Directory (SDD). With some configuration the GroupWise client can be also be downloaded and installed from a web server.

In the past, Novell used its own setup program to install the client; with GroupWise 7 Novell has now introduced support for the industry-standard MSI format to install the GroupWise 7 Client for Windows. Figure 12.1 shows the new installation interface.

Figure 12.1. The new GroupWise 7 InstallShield routine is based on the industry-standard MSI format

At first sight, the net result for the user is the same: He has to walk through the process of installing the client. Figure 12.2 shows the GroupWise client installation that is displayed if the user selects Custom as the installation method.

Figure 12.2. The user gets prompted for installation options

The options include Program Folder name, Add GroupWise to Desktop, Add GroupWise to QuickLaunch, and Add Notify to the Startup Folder, as shown in Figure 12.3.

Figure 12.3. Selectable GroupWise client installation choices

When installing a multilingual version, the user also gets prompted for a default language, as shown in Figure 12.4.

Figure 12.4. Multilingual installation

As shown in Figures 12.2, 12.3, and 12.4, the installation process prompts the user for several kinds of installation decisions the user might not be prepared to make. This chapter discusses the changes introduced by MSI and how to remove the prompts that require users to make installation decisions.

Note

The GroupWise 7 32-bit Windows client runs on the following platforms: Windows 2000 on a Pentium 200 or higher, Windows XP Professional on a Pentium 300 or higher, or Windows 2003 on a Pentium 300 or higher, all with at least 128MB of RAM, plus 60MB of free disk space on the workstation to install the Windows client.

This chapter introduces six ways to install the GroupWise client and describes most of them in-depth:

  • Install the GroupWise client by running SETUP.EXE from the GroupWise 7 Client CD.

  • Install the GroupWise client by running SETUP.EXE from a GroupWise SDD.

  • Distribute the GroupWise client via ZENworks using SETUP.EXE.

  • Distribute the GroupWise client via ZENworks using the GroupWise MSI installation package.

  • Distribute one small executable called SETUPIP.EXE to users and have them run it from their workstations.

  • Upgrade the GroupWise client either via SETUP.EXE when users have rights to the Software Distribution Directory (SDD) or via SETUPIP.EXE when users do not have rights to the SDD.

Note

In past versions of GroupWise, Novell also delivered ZENworks AOT files to deploy the GroupWise client. However, with the introduction of the new MSI-based installation routine, as described in the next section, this option has become obsolete and these files are no longer available.


Understanding the Components That are Part of a GroupWise Installation

The GroupWise Windows client has several integration points into your Windows environment and to the applications installed on Windows. During the installation of the GroupWise client, all these integration points need to be connected, based on the already-installed products. Let's have a look at this:

  • MAPI or Windows Messaging System (WMS) is a Microsoft standard that allows GroupWise, and other MAPI-compliant solutions, to send messages from other applications or from the desktop. In more recent versions of Windows, Microsoft has not always included WMS in the basic Windows installation. The GroupWise installation program will detect this and will install WMS automatically from the CLIENT\WIN32\WMS folder; this version of WMS was created by Microsoft and should run on any Windows box.

    Tip

    In some cases the WMS can get damaged by the installation of certain versions of Microsoft Office, thereby disabling certain integrations with GroupWise. In most cases a reinstallation of WMS from the CLIENT\WIN32\WMS folder will correct these problems.

  • GroupWise Document Management System (DMS) integration is handled via the ODMA interface, which connects the GroupWise DMS with products like Microsoft Word and WordPerfect. The GroupWise installation routine will automatically detect whether any ODMA solutions are installed, and will enable the DMS integration with these solutions. These applications will then redirect certain procedures to GroupWisefor example, the File, Open and File, Save dialogs. Because not everyone uses GroupWise DMS, these integrations can be turned off during the installation manually or via the setup configuration files. Of course, if you install GroupWise first and then add an ODMA-aware application later, you will need to rerun the GroupWise install to enable DMS integration, if needed.

  • Internet Browser Integration will make sure that whenever a user selects a mail-to link or uses the option Read Mail in the browser this will be automatically redirected to GroupWise. This works with most versions of Internet Explorer and the more modern Mozilla Firefox versions. Like WMS, this is a separate part of the installation routine, located in the CLIENT/WIN32/ADDONS/GWMAILTO folder. This option can be manually enabled or disabled during the installation process or via the setup configuration files.

  • Novell PDA Connect is a new addition to GroupWise that will allow you to synchronize your Palm or PocketPC devices via the cradle with GroupWise. The GroupWise installation routine will automatically detect existing installations of HotSync for Palm or ActiveSync for PocketPC. This will fire off a separate installation routine located in the CLIENT\WIN32\ADDONS\PDACONNECT folder. This routine will disable all the default synchronization options of HotSync or ActiveSync (these are now used only as the communication layer with the device) and will enable the integration with GroupWise. Of course, if you install GroupWise first and then add HotSync or ActiveSync afterward, you will need to rerun the GroupWise install to install PDA Connect, if needed.

  • JAWS is a scripting language used to integrate screen readers with mainstream software like GroupWise. JAWS for Windows contains a built-in scripting language that makes mainstream applications more speech friendly and accessible. GroupWise makes the integration of screen readers more user friendly by offering a JAWS script in the CLIENT\JAWS folder.

  • The new GroupWise Connector for Outlook delivers the option to run Outlook 2003 connected to the strong GroupWise back end, as if connected to an Exchange server. A more complete description of this connector can be found at the end of this chapter; the installation routine is located in the CLIENT\CONNECTOR folder.

Most of these modules and options are integrated into a single installation routine; the preceding overview is an illustration of some of the tasks this routine should take care of.


Introducing the GroupWise MSI installation

As mentioned before, an installation of a solution like GroupWise can become quite complex. In the past, all of this was handled by a simple InstallShield script. Although this worked pretty well, due to the added complexity of a modern Windows desktop, Novell has decided to start using the industry-standard MSI format for the installation process of the client. The use of MSI has many advantages; for example, you can easily change an existing MSI installation by creating an MST file, which is a kind of "add-on" that includes your own preferences. Describing MSI in full detail is outside the scope of this book, but here is a summary of the most important benefits:

  • MSI is more tightly integrated with the Windows operating system, which offers many advantages. One example: An MSI install will never overwrite a newer DLL with an older version, meaning no more "DLL Purgatory" because of a newly installed product.

  • Products installed using MSI are "self-healing," meaning that if any part gets somehow damaged, there are options to (automatically) repair the damage.

  • MSI includes rollback options. Instead of having to uninstall a new version that doesn't work as expected, you can quite often simply roll back to an older version.

  • No admin privileges are required by the (installing) user. An MSI install routine will automatically be granted enough privileges to be installed.

  • MSI offers lights-out options. You can distribute the new install package first, and later deploy the software locally at a given time.

  • MSI is table or database oriented, making it possible to use several tools like AdminStudio from InstallShield to "tune" your MSI or MST files.

  • MSI offers more options to integrate with ZENworks. MSI and MST files can be directly connected to a ZENworks installation object, and the combination of these two strong techniques will offer huge benefits.

You can learn more about MSI-based installations combined with ZENworks in certain specialized training sessions, such as the course "MSI, Novell ZENworks & InstallShield AdminStudio: Basics" from Roel van Bueren at http://www.rovabunetworks.nl. In the rest of this chapter we describe the basic usage of this changed MSI installation routine.

Note

During the first betas of GroupWise 7, we've noticed that there is a GroupWise MSI Tuner, which allows you to modify the parameters of an MSI installation. At the moment of writing, it's uncertain whether this utility will be included in the final release; during the beta period it was located in the ADMIN\UTILITY\GWTUNER folder.


Installing the GroupWise Client from CD

First of all, we would like to discuss a "normal" GroupWise installation, but with a bit of a tweak: We will show you how to create a GroupWise 7 Client CD that will install the GroupWise client (more or less) automatically. In this section we will also discuss some of the more general installation issues. This is a good basis for the rest of the chapter, so even if you won't use this installation method, we recommend reading this section. The CD we will create practically mirrors the GroupWise 7 Client CD. However, we will make some changes, and with these changes you can accomplish the following desired effects:

  • The users will place the CD in their CD-ROM drives.

  • The GroupWise Installation will kick off automatically (as long as the users have not disabled auto-run). Otherwise, users must run the SETUP.EXE at the root of the CD. Users will not be prompted with any installation questions.

The next section discusses a scenario regarding the installation requirements, and then shows you how to configure SETUP.CFG based on those goals.

GroupWise Client Installation Requirements Scenario

Following are the requirements of this GroupWise client installation scenario:

  • The default IP address and port for a post office agent (POA) in your GroupWise system will be indicated.

  • Users should not be prompted to answer any installation questions.

  • GroupWise Notify will not be placed in the Windows startup group.

  • Document Integration will be disabled.

  • Users will not be prompted for the language to install; this installation will include two languages, US English and another local language (in this example, Dutch).

  • All other factory defaults are accepted.

Follow these steps to make a GroupWise 7 Client CD:

1. | Copy the entire contents of the GroupWise 7 CLIENT folder to a location on your local hard drive called CLIENTCD.
2. | Go to the CLIENTCD\CLIENT folder. Locate the SETUP.CFG file and copy it to the CLIENTCD\CLIENT\WIN32 folder.
3. | Locate the SETUP.CFG file that you copied to the CLIENTCD\CLIENT\WIN32 folder. Edit the properties of the file in Windows Explorer, and remove the read-only attribute.
4. | Use Windows Notepad to edit the SETUP.CFG file; you should configure the SETUP.CFG and the SETUP.INI files as explained in the next section.

SETUP.CFG and SETUP.INI Changes for the Client

In the SETUP.CFG and SETUP.INI files, make the following changes according to the scenario outlined earlier:

  1. To specify the default IP address and port, remove the semicolon from the following arguments in the SETUP.CFG file: DefaultIPAddress=x.x.x.x and DefaultIPPort=xxxx. Configure them with the IP address and port of a GroupWise POA in the GroupWise System. For example:

    DefaultIPAddress=155.123.178.16
DefaultIPPort=1677

    Tip

    It might be desirable to define a DNS name for the DefaultIPAddress that is publicly resolvable and accessible. By doing this, you will be assured that no matter where the GroupWise client is installed from, the client can find a POA in your organization and log in. You must also configure the public IP address to point to a POA. This can easily be done using network address translation (NAT) from the public address to an internal private address. This concept ties back to the proxy server option discussed in Chapter 8, "Configuring the Post Office Agent."

  2. To ensure that users will not be prompted with installation questions, change the line that reads ShowDialogs=Yes to ShowDialogs=No.

  3. To make sure that Notify is not placed in the Windows startup group, find the line that reads Notify= and change it to Notify=No.

  4. To turn off Document Integration, find the section that reads [IntegrationApps]. After the name of each application containing an =Yes, change it to =No. For example:

    Microsoft Word=No
Microsoft Excel=No
Corel WordPerfect=No

  5. To install a multilingual version, find the section that reads [Languages]. After the name of each language you want to be installed, change =No to =Yes. For example:

    English=Yes
Arabic=No
Dutch=Yes

    Also be sure to set the default language to your desired language, like so:

    Default=English

  6. By default, the GroupWise Client CD has GroupWise configured to ask in which language the installation routine should run, in English or in another language. Even if we disable all dialogs in step 2, users are still prompted about this. To remove this prompt, take the following steps:

    1. Locate the SETUP.INI file, found in the SDD\CLIENT\WIN32 folder.

    2. Edit the properties of the file in Windows Explorer. Remove the read-only attribute, if necessary.

    3. Edit the SETUP.INI file. Find the line that reads EnableLangDlg=Y and change it to EnableLangDlg=N.

Note

The SETUP.CFG and especially the SETUP.INI files have changed quite a lot when compared with the previous GroupWise versions. If you have used earlier versions of these files before, take a look at these differences. For example, the keyword HideAllDialogs=Yes as used in previous versions has been changed to the more intuitive ShowDialogs=No. Be sure not to use a SETUP.CFG file from an older version when installing GroupWise 7.

Testing and Finalizing the Client Installation

Take the following steps to finalize this scenario:

1.
Test this installation by running the SETUP.EXE file in the C:\CLIENTCD folder. If the installation does not behave in the manner you expect, tweak the SETUP.CFG file as needed.

2.
As soon as the installation behaves in the manner you expect, we're almost ready to burn the CD. The root of the CD-ROM folder will be from the contents of C:\CLIENTCD, and in this root there should only be one fileAUTORUN.INF and a single folder called CLIENT. The AUTORUN.INF should contain the following information:

[autorun]
open=client\win32\setup.exe
icon=client\win32\setup.exe,1

If the Autorun on your CD or DVD drive is enabled, the SETUP.EXE file from CLIENT\WIN32 should be automatically started and GroupWise should be installed.


Installing the GroupWise Client by Running SETUP.EXE from a Network Drive

Your users can run the SETUP.EXE file from a GroupWise 7 SDD, but when they do so, by default they will be confronted with a lot of questions that they might not know how to answer, as shown in Figures 12.2, 12.3, and 12.4. It is best to design your GroupWise client installation in such a manner that users do not need to answer any questions regarding what to install and where to install it.

The following section discusses a scenario relating to the installation requirements, and then shows you how to configure the SETUP.CFG and SETUP.INI files based on those goals.

Network Installation Requirements Scenario

Following are the requirements of this GroupWise client installation scenario:

  • The default IP address and port for a POA in your GroupWise system will be indicated.

  • Users should not be prompted to answer any installation questions.

  • Notify will be placed in the Windows startup group.

  • Document Integration will be disabled.

  • Users will not be prompted for the language to install; this installation will include two languages, US English and another local language (in this example, Dutch).

  • All other factory defaults are accepted.

Following are the steps to configuring the GroupWise client installation according to the sample scenario:

  1. Go to the SDD\CLIENT folder. Locate the SETUP.CFG file and copy it to the SDD\CLIENT\WIN32 folder.

  2. Locate the SETUP.CFG file that you copied to the SDD\CLIENT\WIN32 folder. Edit the properties of the file in Windows Explorer, and remove the read-only attribute, if necessary.

You are now ready to make changes to the use an editor such as Windows Notepad to edit the SETUP.CFG file; you should configure the SETUP.CFG and the SETUP.INI files, as explained in the next section.

Network Installation SETUP.CFG and SETUP.INI Changes

In the SETUP.CFG and SETUP.INI files, make the following changes according to the scenario outlined earlier:

  1. To specify the default IP address and port, remove the semicolon from the following arguments in the SETUP.CFG file: DefaultIPAddress=x.x.x.x and DefaultIPPort=xxxx. Configure them with the IP address and port of a GroupWise POA in the GroupWise System. For example:

    DefaultIPAddress=155.123.178.16
DefaultIPPort=1677

    Tip

    It might be desirable to define a DNS name for the DefaultIPAddress that is publicly resolvable and accessible. By doing this, you will be assured that no matter where the GroupWise client is installed from, the client can find a POA in your organization and log in. You must also configure the public IP address to point to a POA. You can easily do this using network address translation (NAT) from the public address to an internal private address. This concept ties back to the proxy server option discussed in Chapter 8.

  2. To ensure that users will not be prompted with installation questions, change the line that reads ShowDialogs=Yes to ShowDialogs=No.

  3. To make sure that Notify is not placed in the Windows startup group, find the line that reads Notify= and change it to Notify=No.

  4. To turn off Document Integration, find the section that reads [IntegrationApps]. After the name of each application containing a =Yes, change it to =No. For example:

    Microsoft Word=No
Microsoft Excel=No
Corel WordPerfect=No

  5. To install a multilingual version, find the section that reads [Languages]. After the name of each language you want to be installed, change =No to =Yes. For example:

    English=Yes
Arabic =No
Dutch=Yes

    Also be sure to set the default language to your desired language, like so:

    Default=English

  6. By default, the GroupWise Client CD has GroupWise configured to ask in which language the installation routine should run, in English or in another language. Even if we disable all dialogs in step 2, users are still prompted about this. To remove this prompt, follow these steps:

    1. Locate the SETUP.INI file, found in the SDD\CLIENT\WIN32 folder.

    2. Edit the properties of the file in Windows Explorer. Remove the read-only attribute, if necessary.

    3. Edit the SETUP.INI file. Find the line that reads EnableLangDlg=Y and change it to EnableLangDlg=N.

Note

The SETUP.CFG and especially the SETUP.INI files have changed quite a lot when compared with the previous GroupWise versions. If you have used earlier versions of these files before, take a look at these differences. For example, the keyword HideAllDialogs=Yes as used in previous versions has been changed to the more intuitive ShowDialogs=No. Be sure not to use a SETUP.CFG file from an older version when installing GroupWise 7.

Now SETUP.CFG and SETUP.INI have the changes made that will ensure that users do not have to make installation choices.

Testing and Finalizing the Network Installation

Take the following steps to finalize this scenario:

1. | Test this installation by running the SETUP.EXE file in the SDD\CLIENT\WIN32 folder. If the installation behaves in the manner you expect, proceed to the next step. If it does not behave in the manner you expect it to, tweak the SETUP.CFG file as needed.
2. | Allow your users network rights to the SDD\CLIENT folder and subdirectories. Do not allow your users to have rights to the SDD folder or any of its directories other than the \CLIENT folder and its subdirectories.

You now have in place a solution that will allow your users run the SETUP.EXE file from the SDD\CLIENT\WIN32 folder. You can also execute the SETUP.EXE file from a Novell Client login script.


Distributing the GroupWise Client via ZENworks

If your organization has implemented ZENworks, distributing the GroupWise 7 client can be pretty sweet. With ZENworks and GroupWise 7, you now have two methods to distribute the GroupWise client:

  • Integrate the GroupWise SETUP.EXE routine with a suitable SETUP.CFG into a ZENworks installation object. In the past this option was certainly one of the more interesting and successful ways to deploy GroupWise, but now we also have a very interesting new option.

    Tip

    One of the complications of the method just mentioned can be the fact that some part of an older version of the GroupWise client, like Notify, might still be running. With earlier versions of GroupWise, Novell therefore included a little application called SHUTDOWN.EXE, which will close all active GroupWise applications. This nifty little tool can be found in the CLIENT/ZEN folder of one of these earlier versions and can be useful for upgrades to GroupWise 7 from an earlier version.

  • Integrate the GroupWise MSI file into a ZENworks installation object. If you're using a more recent version of ZENworks, you should probably already be aware of the many advantages of MSI-based installation packages. And if you're using an older version of ZENworks, this could certainly be a reason to upgrade. We mentioned some of the advantages in one of the earlier sections of this chapter; however, a further discussion of creating a MSI installation object in ZENworks does not fit within the scope of this book.

Note

In earlier versions of GroupWise, Novell also delivered ZENworks AOT files to deploy the GroupWise client. However, with the introduction of the new MSI-based installation routine, as described in one of the previous sections, this option has become obsolete and these files are not available anymore.


Creating a SETUPIP GroupWise Client Distribution System

The GroupWise client can be distributed through a system called SETUPIP. SETUPIP requires a client and a server/host. The SETUPIP Client is called SETUPIP.EXE. The SETUPIP Host is a web server that serves up a compressed GroupWise install set called a SETUPIP Client Distribution Set.

The advantage to distributing the GroupWise client via the SETUPIP method is that users do not need to have file-system rights to a server to install the GroupWise client.

This section explains all the aspects of creating a SETUPIP GroupWise Client Distribution System. SETUPIP Host configuration instructions given in this chapter are specific to Apache on NetWare 6.5 and Apache on SUSE Linux Enterprise Server 9. However, you can model the instructions given in this chapter to try to implement a SETUPIP Host on other flavors of web servers.

Note

You must have a web server of some sort. The web server must allow connections on port 80, the standard HTTP port.

Creating the SETUPIP.EXE Client Utility

The SETUPIP.EXE Client utility is a file that you actually generate. Here are the steps you must complete to create the SETUPIP.EXE Client utility:

1.
In your GroupWise 7 Software Distribution Directory, run WRITEIP.EXE from the ADMIN\UTILITY\SETUPIP directory.

2.
In the first IP address field, indicate the IP address or DNS address of a web server at your site that can serve up the GroupWise client files. The server must be able to support port 80 connections. Also, specify a path in the address field that will actually represent the directory location off of the web server that will end up containing GroupWise client files. You will actually create this directory in the next section. In our sample system we indicated the following two locations:

http://wwwfs1.wwwidgets.com/gw7cl
http://wwwfs2.wwwidgets.com/gw7cl

SETUPIP can support the notion of failover SETUPIP Host web servers. So you can fill in the additional IP addresses as desired. Additionally, if you choose the option Choose IP addresses at random, SETUPIP will be enhanced to randomly try downloading from any one of the SETUPIP Host web servers.

3.
Configure the download options as you desire. See Figure 12.5, which shows an example of the WRITEIP utility configured to generate a new SETUPIP.EXE.

Figure 12.5. The WRITEIP utility configured to create a new SETUPIP.EXE Client

[View full size image]

4.
When everything is configured correctly, click OK and the new SETUPIP Client file SETUPIP.EXE will be created in the ADMIN\UTILITY\SETUPIP directory. Later in this chapter you will be told what to do with the newly created SETUPIP.EXE file, but let's set that topic aside for a moment.

Although the SETUPIP utility is created, and can be executed, it will error out if you run it, because you must implement the rest of the SETUPIP GroupWise Client Distribution System.

Configuring the SETUPIP Host Web Server

The SETUPIP Client expects a SETUPIP Client Distribution Set, which is a handful of files and a directory path that should be present and served up at the HTTP location you specified in the WRITEIP utility. The directory path should be under the web server's "document root" folder. The name of the directory path you create should correlate to the name of the directory path you indicated earlier in the WRITEIP utility. So in our example, the directory path should be a directory called gw7cl, under the web server's document root directory. So, for example, on a typical NetWare 6.5 server, you would create the gw7cl directory off of SYS:APACHE2\HTDOCS. After the directory path is created, there are specific files you will want to put in place.

Right now, though, is a good time to make this discussion more specific to the version of web server you are using. We'll first review the steps to creating the SETUPIP Host on the NetWare 6.5 platform. And then we'll explain the exact same steps relative to Apache on a SUSE Linux Enterprise Server 9 server. The methods we employ for these web servers should be sufficient for you to implement a SETUPIP Host on whatever web server platform you happen to have.

Configuring the SETUPIP Host Web Server on NetWare 6.5

The SETUPIP Host web server generally does not need any specific "configuration"; it's all about creating the directories and placing the files that will make a correctly configured SETUPIP Client Distribution Set. Your Apache web server, though, should allow for connections on the standard HTTP port, which is port 80.

In our sample scenario, we will use each of the steps indicated on the servers that host the DNS names: wwwfs1.wwwidgets.com and wwwfs2.wwwidgets.com. The reason for this is that when we ran the WRITEIP utility earlier, we indicated that both of these servers were going to be available to serve SETUPIP Client requests:

  1. Create a directory off of the document root folder that correlates to the directory you specified in the WRITEIP utility. In our example, the directory will be named GW7CL. On a NetWare 6.5 server, typically the document root folder is on the server's SYS volume at the path ..\APACHE2\HTDOCS. So the full path to the new SETUPIP Client Distribution Set in our example will be as follows:

    \\WWWFS1\SYS\APACHE2\HTDOCS\GW7CL

  2. Off of the ..\APACHE2\HTDOCS\GW7CL directory, create a directory called WIN32. So the path will be this:

    \\WWWFS1\SYS\APACHE2\HTDOCS\GW7CL\WIN32

  3. Locate the following two files and place them in the ..APACHE2\HTDOCS\GW7CL directory: SETUPIP.FIL and SETUPIP.LANGUAGE. In our example, it will be a file by the name of SETUPIP.US. However, for German the name of the file would be SETUPIP.DE, or for French it would be SETUPIP.FR, and so forth.

    If you would like your SETUPIP Client Distribution Set to have multiple languages, you can put in multiple SETUPIP.LANGUAGE files. The location of these SETUPIP.LANGUAGE files may depend on how you obtained your GroupWise media, or the language you are using. With the software we were using when writing this chapter, these files were located in the GroupWise 7 SDD in ADMIN\UTILITY\SETUPIP. However, you may need to find these files in some other location based on the GroupWise 7 media you have obtained.

  4. Copy a properly configured GroupWise client SETUP.CFG and a SETUP.INI file from your GroupWise 7 SDD to the APACHE2\HTDOCS\GW7CL\WIN32 directory on the SETUPIP Host web server.

    For instructions on configuring these files, see the sections earlier in this chapter titled "GroupWise Client Installation Requirements Scenario" and "SETUP.CFG and SETUP.INI Changes." By default, the SETUP.CFG file is in the GroupWise 7 SDD\CLIENT directory, and the SETUP.INI file is in the GroupWise 7 SDD\CLIENT\WIN32 directory.

    If you would like your SETUPIP Host server to allow for multiple GroupWise Client language installation types, be sure to configure the SETUP.CFG and SETUP.INI files correctly. Specifically, you will want SETUP.CFG to indicate more than one Language type. SETUP.INI should allow for a Language Selection dialog. See the sections earlier in this chapter titled "Network Installation Requirements Scenario" and "SETUP.CFG and SETUP.INI Changes" for more guidance on this subject. Also, as mentioned just a couple of paragraphs ago, you will need the correct SETUPIP.LANGUAGE file(s) to represent the languages you want users to have the choice to install.

Now that you have both the SETUPIP Client and the SETUPIP Host configured, you have a complete SETUPIP GroupWise Client Distribution System. The ..\GW7CL directory should look similar to what's shown in Figure 12.6.

Figure 12.6. The contents of the GW7CL directory

[View full size image]

The ..\GW7CL\WIN32 directory should look similar to what's shown in Figure 12.7.

Figure 12.7. The contents of the GW7CL\WIN32 directory

[View full size image]

Now you need to test your SETUPIP System, and perfect it if needed. To test it, simply run the SETUPIP Client utility you created earlier. It's called SETUPIP.EXE, and by default it's located in the GroupWise 7 SDD\ADMIN\UTILITY\SETUPIP directory. When you run SETUPIP.EXE, you should see a dialog similar to the one shown in Figure 12.8. After SETUPIP.EXE downloads and extracts the GroupWise Client, the regular GroupWise Client SETUP.EXE runs.

Figure 12.8. The SETUPIP Client utility SETUPIP.EXE downloading the GroupWise client

If you run into problems getting SETUPIP to work, make sure that the Apache web server is running. You may also want to confirm that the Apache web server is listening on port 80. The command to load Apache on a NetWare 6.5 server is as follows:

apache2

To further troubleshoot and configure your Apache web server on NetWare 6.5, you may need to stray into the configuration file for Apache. Typically the configuration file is SYS:APACHE2\CONF\HTTPD.CONF. Also, note that case sensitivity is important to Apache, so be sure to keep the filename lowercasefor example, httpd.conf. The common writing convention in this book shows filenames in uppercase, so we refer to files in uppercase format. Generally on NetWare the case of a file does not matter, but to Apache it does.

Configuring the SETUPIP Host Web Server on SLES9 Server

The SETUPIP Host web server generally does not need any specific "configuration"; it's all about creating the directories and placing the files that will make a correctly configured SETUPIP Client Distribution Set. Your Apache web server, though, should allow for connections on the standard HTTP port, which is port 80.

In our sample scenario, we will use each of the steps indicated on the servers that host the DNS names: wwwfs1.wwwidgets.com and wwwfs2.wwwidgets.com. The reason for this is that when we ran the WRITEIP utility earlier, we indicated that both of these servers were going to be available to serve SETUPIP Client requests:

  1. Create a directory off of the document root folder that correlates to the directory you specified in the WRITEIP utility. In our example, the directory will be named GW7CL. On a SLES9 server you actually may have multiple instances of Apache installed. In our environment, the HTDOCS directory was at the following path: /var/opt/novell/httpd/htdocs. So the full path to the new SETUPIP Client Distribution Set in our example will be as follows:

    /var/opt/novell/httpd/htdocs/gw7cl

  2. Off of the ../httpd/htdocs/gw7cl directory, create a directory called win32. So the path will be this:

    /var/opt/novell/httpd/htdocs/gw7cl/win32

  3. Locate the following two files and place them in the ../httpd/htdocs\gw7cl directory: SETUPIP.FIL and SETUPIP.LANGUAGE. In our example, it will be a file by the name of SETUPIP.US. However, for German the name of the file would be SETUPIP.DE, or for French it would be SETUPIP.FR, and so forth.

    If you would like your SETUPIP Client Distribution Set to have multiple languages, you can put in multiple SETUPIP.LANGUAGE files. The location of these SETUPIP.LANGUAGE files may depend on how you obtained your GroupWise media, or the language you are using. With the software we were using when writing this chapter, these files were located in the GroupWise 7 SDD in ADMIN\UTILITY\SETUPIP. However, you may need to locate these files in some other location based on the GroupWise 7 media you have obtained.

  4. At the time we wrote this book, we noted that the SETUPIP.FIL and SETUPIP.US files needed to be named in a very specific manner to work correctly. You may know that on Linux files, case is very important. And in fact the SETUPIP Client utility is actually asking for the SETUPIP.FIL and the SETUPIP.US files with a certain file case. Here is the case we had to make sure that the files were in, in order to get SETUPIP to work:

    SetupIP.fil

    and

    SetupIP.US

    So if, when I copied over the SETUPIP.FIL file, it was actually named setupip.fil on the Linux server, I would need to rename the file. From a terminal session on the Linux server, I would type the following command:

    mv setupip.fil SetupIP.fil

    If the SETUPIP.US file is actually named setupip.us, I would need to rename the file. From a terminal session on the Linux server, I would type the following command:

    mv setupip.us SetupIP.US

  5. Copy a properly configured GroupWise client SETUP.CFG file and a SETUP.INI file from your GroupWise 7 SDD to the /var/opt/novell/httpd/htdocs/gw7cl/win32. Make the case of both of these files lowercase.

    For instructions on configuring these files, see the sections earlier in this chapter titled "GroupWise Client Installation Requirements Scenario" and "SETUP.CFG and SETUP.INI Changes." By default, the SETUP.CFG file is in the GroupWise 7 SDD\CLIENT directory, and the SETUP.INI file is in the GroupWise 7 SDD\CLIENT\WIN32 directory.

    If you would like your SETUPIP Host server to allow for multiple GroupWise Client language installation types, be sure to configure the SETUP.CFG and SETUP.INI files correctly. Specifically, you will want the SETUP.CFG file to indicate more than one Language type. The SETUP.INI file should allow for a Language Selection dialog. See the sections earlier in this chapter titled "Network Installation Requirements Scenario" and "SETUP.CFG and SETUP.INI Changes" for more guidance on this subject. Also, as mentioned just a couple of paragraphs ago, you will need the correct SETUPIP.LANGUAGE file(s) to represent the languages you want users to have the choice to install.

Now that you have both the SETUPIP Client and the SETUPIP Host configured, you have a complete SETUPIP GroupWise Client Distribution System. The ../gw7cl directory and contents under the directory should look similar to what's shown in Figure 12.9.

Figure 12.9. The contents of the gw7cl directory and subdirectories on a SLES9 Server

Now you need to test your SETUPIP System, and perfect it if needed. To test it, simply run the SETUPIP Client utility you created earlier. It's called SETUPIP.EXE, and by default it's located in the GroupWise 7 SDD\ADMIN\UTILITY\SETUPIP directory. When you run the SETUPIP.EXE, you should see a dialog similar to the one shown in Figure 12.10. After SETUPIP.EXE downloads and extracts the GroupWise Client, the regular GroupWise Client SETUP.EXE runs.

Figure 12.10. The SETUPIP Client utility SETUPIP.EXE downloading the GroupWise client

If you run into problems getting SETUPIP to work, make sure that the Apache web server is running. You may also want to confirm that the Apache web server is listening on port 80. The command to load Apache on our SLES9 server is as follows:

/etc/opt/novell/httpd/init.d/httpd start

The command to start Apache on your Linux server could very well be different. To further troubleshoot and configure your Apache web server on Linux, you may need to stray into the configuration file for Apache. The *.conf file on our SLES9 server is /etc/opt/novell/httpd/conf.d. Also, note that case sensitivity is important to Apache, so be sure to keep the filename lowercase.

The Apache error log file is also a good place to go for troubleshooting purposes. On our SLES9 server the error log was located at /var/opt/novell/httpd/logs/error_log.

When writing this chapter, we used the Apache error_log to determine that the SETUPIP Client was trying to find the SETUPIP.* files with a particular case. So using the error_log file for troubleshooting is really handy.

Troubleshooting SETUPIP

The SETUIP Client utility creates an error log called SETUPIP.ERR if SETUPIP.EXE encounters an error condition. This file is created in the Windows root program folder, such as C:\WINNT. Here is an example of the contents of our SETUPIP.ERR file in our test system:

137.65.55.215 - The file SetupIP.US was not found. (200)

Another good place to go for troubleshooting purposes is the error log of the web server. For example, the Apache error log file is also a good place to go for troubleshooting purposes for the Apache web server.


Upgrading the GroupWise Client via a Network Drive

The following section assumes that the GroupWise client is already installed on the user's desktop and you are upgrading to a newer version of the GroupWise client.

For you to understand how to upgrade a GroupWise client, it's advantageous for you to consider several issues first. These are discussed in the following sections.

The Auto-Update Algorithm

The auto-update algorithm is how the GroupWise client, installed in the users' computers, knows it should upgrade itself to a newer version of the GroupWise client. By using the auto-update algorithm, you can automate the process of upgrading the GroupWise client to the GroupWise 7 client without the users having to initiate the setup process. Here's how it works.

GroupWise has a Software Distribution Directory (SDD), a folder that houses the GroupWise software after it has been installed or copied from the Novell GroupWise CD. When patches are released, they are applied to a GroupWise SDD. Not only is a GroupWise SDD a location for software, but it can be defined in GroupWise Administration and assigned to post offices. In GroupWise 7 using ConsoleOne, the GroupWise SDD is defined under Tools, GroupWise System Operations, Software Directory Management. See Figure 12.11.

Figure 12.11. SDD Management

A GroupWise SDD has a value called a bump number associated with it. The bump number starts at 0 and can be incremented to 1, and then 2, and then 3, and so on. Controlling the bump number is essential to controlling the GroupWise client upgrade process.

Every GroupWise post office should have an SDD associated with it. In fact, when you create a GroupWise post office, one of the required fields is the SDD that will be associated with the post office. You can configure an SDD that can be used by several post offices. For upgrade purposes, creating post officespecific SDDs is often the best practice. An SDD is used primarily so that the GroupWise client knows where to look in order to upgrade itself to a newer version of GroupWise. Even if you intend to use a solution such as ZENworks, GroupWise requires you to define which SDD is to be used by each post office. To see or change the SDD associated with a GroupWise post office, view the properties of that post office and select the Post Office Settings property page from the GroupWise tab. See Figure 12.12.

Figure 12.12. The SDD associated with a post office

[View full size image]

The GroupWise SDD should, and typically will, have the GroupWise 32-bit client installed. The GroupWise client is located in the SDD\CLIENT folder. Sites that intend to use the GroupWise SDD for GroupWise client software distribution must grant users Read and File Scan rights to the SDD\CLIENT folder and its subfolders. Users should not have rights in any other location of the SDD. If you are using ZENworks or a similar solution, or if you use SETUPIP, explained elsewhere in this chapter, your users should not have any rights to the SDD.

To construct an SDD for a post office, make a folder called GW70SDD under the post office folder. Copy the CLIENT folder and its contents from the master GroupWise 7 SDD to the GW70SDD folder under the post office.

Warning

When you define an SDD, the path to the SDD should not include the directory CLIENT. The CLIENT portion is assumed, so the folder that is the parent to the CLIENT folder is where the SDD should point.

In the SDD\CLIENT folder are two files that are an essential part of the GroupWise upgrade, as well as the auto-update algorithm. These files are SOFTWARE.INF and SETUP.CFG. In addition to these files from the SDD, a value in the WPDOMAIN.DB and the WPHOST.DB files, known as the bump number, is an essential part of the auto-update algorithm. All of these factors are detailed here:

  • The SETUP.CFG file resides in the SDD\CLIENT folder. This is a "template" file that allows the administrator to customize the way in which the GroupWise client is installed at the user's workstation. The SETUP.CFG file should be copied to the CLIENT\WIN32 folder and modified according to the administrator's preferences for the install of the GroupWise client. The important settings for the SETUP.CFG file as pertains to the auto-update algorithm are under the [AutoUpdate] section. The Enabled value must be set to Yes for the automatic update to occur.

  • The SOFTWARE.INF file is an ASCII file containing a small amount of information. In fact, here are the entire contents of the SOFTWARE.INF file from the GroupWise 7 SDD:

    [General]
BuildNumber=3004

    The BuildNumber is really the version number in development terms. But to you and me, GroupWise releases versions of the GroupWise software in versions that we typically know as 6.5, 6.5.4, and 7.0. The BuildNumber of 3004 is the GroupWise 7 client at the moment of writing this book. The BuildNumber version of the GroupWise 6.5 Support Pack #4 client is 2615.

    Now here's what the BuildNumber means to the auto-update algorithm. Whenever the GroupWise client is installed, the BuildNumber of the GroupWise client is placed into the Windows Registry, as shown in Figure 12.13. The BuildNumber string value is kept in the following location:

    Figure 12.13. The GroupWise BuildNumber in the Windows Registry

    [View full size image]

    HKEY_LOCAL_MACHINE\SOFTWARE\Novell\GroupWise

The Bump and Build Numbers

It is important to understand the relevance of the BuildNumber value. You might remember that every GroupWise post office has an SDD associated with it. The SDD has a bump number associated with it. Each time the GroupWise client loads, it asks for the bump number associated with the SDD for the user's post office. This bump number is obtained for the GroupWise client from the WPHOST.DB file. When the GroupWise client loads and contacts the POA, the conversation goes something like this:

CLIENT: Hi, post office agent (POA) at IP address 192.168.100.237, port 1677. I need a client/server session with you. Here are my authentication credentials.

POA: Here's a client/server session, and here's the port we will use to speak.

CLIENT: Hey, POA, before I load the user interface of this client, what is the bump number for the SDD associated with my post office?

POA: It's 5.

CLIENT: Okay, let's see, the last time I installed the GroupWise client, the bump number was 4. This is held in the Windows Registry at the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\GroupWise\Client\5.0

The value is called NewSoftwareBump. In this example, you see that the bump number for the SDD is different from the bump number in the Windows Registry. Thus, the GroupWise client must look further to see whether it is essential to upgrade the GroupWise client. Let's keep going:

CLIENT: Hey, POA, what's the location of my SDD?

POA: It's in the WWWFS1\VOL1\CORPPO\GW70SDD folder.

CLIENT: Okay, let me look at the SOFTWARE.INF file from the CORPPO\GW70SDD\CLIENT folder. The BuildNumber is 3004 in the SOFTWARE.INF file, and the BuildNumber in the Windows Registry on my machine is 1807. It seems like it's time to upgrade. Now let me find the SETUP.CFG file from the SDD\CLIENT folder to see whether the [AutoUpdate] section of this file has a line that reads Enabled=Yes. Yes, it does! It's upgrade time!

Here is a quick synopsis of what has transpired:

  • If the bump number for the SDD associated with a post office is different (not higher per se, just different) than the bump number in the Windows Registry, the client compares the build number in the SOFTWARE.INF file with the build number in the Windows Registry.

  • If the build number in the SOFTWARE.INF file is greater than the build in the Windows Registry, the GroupWise client looks at the SETUP.CFG file.

  • If the [AutoUpdate] section in the SETUP.CFG file contains Enabled=Yes, the GroupWise client will attempt to upgrade itself.

  • The GroupWise client can then upgrade itself by launching SETUP.EXE from the SDD\CLIENT\WIN32 folder, or by launching SETUPIP.EXE that the POA sends to the GroupWise client that it retrieved for the client from the SDD\CLIENT\WIN32 folder.

This section explained the auto-update algorithm, which is essential to understand if you want the GroupWise client to update automatically.

Upgrading All Users on a Post Office with a Mapped Drive to the GroupWise SDD

The GroupWise administrator can fully configure what users will see during the GroupWise client upgrade, and just what will be installed. Before covering the upgrade steps, let's walk through an example. The following example looks at WorldWide Widget Corporation's technical directives with regard to the upgrade of the GroupWise client:

  • Users will be forced to upgrade/update their GroupWise clients.

  • The default IP address and port for a POA in the system will be indicated.

  • Users should not be prompted to answer any installation questions.

  • Notify will not be placed in the Windows startup group.

  • Document Integration will be disabled.

  • Users will not be prompted for the language to install; this installation will include two languages, US English and another local language (in this example, Dutch).

  • All other factory defaults for the installation are accepted.

The following steps are sample procedures for upgrading a post office. After reading this section, you should be able to modify this scenario to match the needs of your organization:

1. | Physically create and configure a slimmed-down GroupWise 7 SDD. To do this, create a folder within the post office folder called GW70SDD and copy the GroupWise 7 SDD\CLIENT folder structure to the post office\GW70 folder. In the end, you will have a folder structure that looks like this: Post Office Directory\GW70SDD\CLIENT. The SDD you create needs a full copy of the CLIENT folder and subfolders from a GroupWise 7 SDD. Note You are welcome to place the SDD in some other location than the post office folder. As long as the users have rights to the location and no other folders or files in the post office folder structure, you can place it in the post office folder.
2. | Go to the SDD\CLIENT folder. Locate the SETUP.CFG file and copy it to the SDD\CLIENT\WIN32 folder.
3. | Locate the SETUP.CFG file that you copied to the SDD\CLIENT\WIN32 folder. Edit the properties of the file in Windows Explorer, and remove the read-only attribute, if necessary.
4. | Use Windows Notepad to edit the SETUP.CFG file.

The next order of business is to make changes to the files. See the sections earlier in this chapter titled "GroupWise Client Installation Requirements Scenario" and "SETUP.CFG and SETUP.INI Changes." In addition, change the line in the SETUP.CFG file that reads ForceUpdate=No to ForceUpdate=Yes to force users to update.

Testing the Installation

You still have a little ways to go, but to confirm that your SETUP.CFG and SETUP.INI files are configured correctly, run the SETUP.EXE file in the SDD\CLIENT\WIN32 folder. If the installation behaves in the manner you expect, proceed to the next section. If it does not behave in the manner you expect, tweak the SETUP.CFG file as needed.

Defining a GroupWise SDD

To logically define the newly created GroupWise 7 SDD, follow these steps:

1.
Go into ConsoleOne. Be sure to connect to the primary domain.

Tip

Whenever you are going to make a change or an addition through System Operations, it is best to be connected to the primary domain.

2.
In ConsoleOne, select Tools, GroupWise System Operations, Software Directory Management.

3.
Click the Create button. Give the SDD a name and a descriptionfor example, Corporate Post Office SDD. Define the UNC path to the SDD, which in these examples is the post office folder\GW70SDD folder. The UNC path should not point all the way to the post office folder\GW70SDD\CLIENT folder, because the CLIENT portion is assumed. See Figure 12.14.

Figure 12.14. A newly defined GroupWise 7 SDD

4.
Click OK and then Close to get to the main ConsoleOne screen.

This section described how to create an SDD. Now you need to select an SDD to associate with the post office.

Selecting an SDD for a Post Office

The steps to assign the new GroupWise 7 SDD to the post office are as given here:

1. | Edit the properties of the post office and select the Post Office Settings property page from the GroupWise tab.
2. | In the SDD field, select the appropriate SDD for this post office, and then click OK.

This might be enough to kick off the auto-update process. But there's also a chance that it isn't. If the original GroupWise 6.x SDD for the post office you are upgrading had the same bump number as the SDD for the GroupWise 7 SDD you just created, the GroupWise client doesn't pick up on a bump-number change. A change in the bump number is the first part of the auto-update algorithm, so the bump number must change before GroupWise will discover the new GroupWise client it should upgrade to. If the upgrade process does not seem to be happening, and you want it to, you can proceed to the steps outlined under the next task.

This section simply talked about how to associate an SDD with a post office. This might have been enough to kick off the upgrade, and it might not have been. Be sure to take the steps explained in the next section.

Updating the Bump Number of a GroupWise SDD

To initiate the GroupWise client upgrade with the Update feature, follow these steps:

1. | Go into ConsoleOne and connect to the primary domain.
2. | In the GroupWise view in ConsoleOne, select Tools, GroupWise System Operations, Software Directory Management.
3. | Highlight the new GroupWise 7 SDD you recently created and click the Update button.
4. | In the next dialog box, select the check box for Force Auto-Update Check by GroupWise Components. Click the OK button.
5. | If needed, repeat steps 14 if users are not being prompted to upgrade their GroupWise clients. Remember that users will be prompted to upgrade only if the BuildNumber in their local Registry is lower than the BuildNumber in the SDD\CLIENT\SOFTWARE.INF file.

Now that all of the steps are in place, the users should be prompted to upgrade their GroupWise client the next time they log into GroupWise.

Upgrading the GroupWise Client with SETUPIP

To use SETUPIP, you must have already configured a SETUPIP GroupWise Client Distribution System as explained earlier in this chapter.

After the SETUPIP System is working, you can take the SETUPIP Client SETUPIP.EXE and distribute it in whatever manner you would like. For example, you can post it to a web page, or you can email it to users and tell them to right-click on the SETUPIP.EXE file and select Open.

You can also design your GroupWise post office to use SETUPIP as the upgrade mechanism. This is what the users will experience:

  1. Users are prompted to upgrade, and they are presented with two buttons: OK and Cancel.

  2. After the user has clicked OK, SETUPIP downloads the GroupWise client software from the web server.

  3. After the GroupWise client is downloaded and expanded, the Windows Client Setup screen shows when the SETUP.EXE program is launched. The GroupWise client installs.

By using the SETUPIP Client installation method, you eliminate the need for users to have rights to a network drive. Also, the installation process creates less network traffic when SETUPIP is used.

Here's how you configure GroupWise so that when users are prompted to upgrade, they will launch SETUPIP.EXE:

  1. Follow all the steps in the section of this chapter titled "Creating a SETUPIP GroupWise Client Distribution System."

  2. Follow all the steps in the section of this chapter titled "Upgrading the GroupWise Client via a Network Drive." Make sure that the POA has rights to access the SDD for the post office to be upgraded. The GroupWise POA will scoop up the SETUPIP.EXE and some other files on behalf of the GroupWise client running at the desktop, and send them down to the GroupWise client to execute SETUPIP.EXE locally. If the POA needs to scoop up files from the SDD, the POA must have rights to the SDD. You can assign these rights by adding the /user and /password switches in the startup file of the POA, or you can place the SDD on the same server where the post office is located, and where the POA is executing.

  3. Make sure that users do not have rights to the SDD for the post office, or their clients will not be prompted to install via SETUPIP. Instead, their clients will execute SETUP.EXE.

  4. Place the SETUPIP.EXE in the Post Office SDD\CLIENT\WIN32 folder.

  5. Edit the SETUP.CFG file in the Post Office SDD\CLIENT\WIN32 folder. Make this additional change to the SETUP.CFGfind the argument that reads SetupIPEnabled=No and change it to SetupIPEnabled=Yes.

This section explained how to get the SETUPIP.EXE utility to launch automatically without users taking any action.


Adding Grace Logins Before a Forced Upgrade

You might want to allow your users some grace logins before they are forced to upgrade their GroupWise clients. This allows users the flexibility to install the GroupWise client at a more convenient time.

To do this, you need to edit SETUP.CFG in the GroupWise 7 SDD assigned to the post office. In addition to the changes to the SETUP.CFG file explained earlier in this chapter, you should put a value in the GraceLoginCount= argument. For example, if you wanted the users to have five grace logins before upgrading, the setting would look like this:

GraceLoginCount=5

The GraceLoginCount= argument, when combined with ForceUpdate=Yes, causes the GroupWise client installation to allow for grace logins before users are forced to upgrade their clients.


Forcing a Windows Registry Change Through SETUP.CFG

This section is only for those of you who are very savvy with the Windows Registry. You can define Windows Registry settings and changes that you might want to make. If there's a Registry setting that you know the GroupWise client installation makes, yet you want to specify a different setting, follow these steps:

1.
Edit the SETUP.CFG file, either in the SDD or on the web server if you are using SETUPIP.

2.
Add the following syntax to SETUP.CFG for the Registry setting you want to define or change:

[Registry Setting x]
Action=Add or Delete
Type=String or DWORD
Key=<Key Name>
Name=<Value Name>
Value=<Value to set>

Here are a few examples:

This change will add a value named BuildNumber under the GroupWise key set to 2085:

[Registry Setting 1]
Action=Add
Type=DWORD
Key=HKEY_LOCAL_MACHINE\SOFTWARE\Novell\GroupWise
Name=BuildNumber
Value=2085

This change will delete a value named BuildNumber under the GroupWise key:

[Registry Setting 2]
Action=Delete
Key=HKEY_LOCAL_MACHINE\SOFTWARE\Novell\GroupWise
Name=BuildNumber

This change will delete the GroupWise key and all subkeys (use this one with caution):

[Registry Setting 3]
Action=Delete
Key=HKEY_LOCAL_MACHINE\SOFTWARE\Novell\GroupWise

This section explained how the GroupWise installation can also roll out or delete Registry settings.


Auditing the GroupWise Client Upgrade

Following are steps you can take to determine who has upgraded/updated their GroupWise client:

1.
The GroupWise POA has a feature that can give you a quick look at who has upgraded the GroupWise client to GroupWise 7. For you to be able to see this feature, your GroupWise POA should support HTTP monitoring and your post office should support some other features. You can enable HTTP monitoring in ConsoleOne or in the startup file of the POA; using ConsoleOne is recommended.

2.
Open the properties of the GroupWise Post office object, Client Access Settings.

3.
From there, you will see two sections that allow you to define the minimum client release version and date. From the Minimum Client Release Version (x.x.x), you can choose a version of the GroupWise client from a drop-down list, or if the version of the client you are interested in is not listed, you can type the version number of the GroupWise client you are interested in monitoring. In the Minimum Client Release Date field, you can check the calendar icon to specify a date of the GroupWise client release. Notice that when you select a predefined version, the date field is entered automatically for this particular version of the GroupWise client. You should verify that this information is correct by checking the GroupWise client from Help, About GroupWise. This will tell you the release date and version of this particular client.

4.
After enabling these settings on the post office, click OK to apply them.

5.
Go to the POA's HTTP port in this manner from your web browser at http://207.40.197.201:7181.

Note

If you are not sure what HTTP port your POA is using, you can access the C/S port (1677) and it will redirect you to the HTTP port.

6.
You might be prompted for a username and password. After you've accessed the POA via HTTP, go to the C/S Users link. From there, you can view the version of GroupWise client that your various users are using. Any user who is using an older GroupWise client than you specified will appear in red. Any user who is using a newer GroupWise client will appear in blue. See Figure 12.15 for an example of the screen.

Figure 12.15. Using the POA's HTTP monitoring screen

[View full size image]

This section explained how to monitor a GroupWise client upgrade with help from the GroupWise POA HTTP monitoring screen.


Understanding the GroupWise Login Process

Understanding the login process is helpful when you're configuring your GroupWise system to support the GroupWise client login process. It's also helpful to understand the login process when you're troubleshooting login difficulties.

When you double-click the GroupWise application, the client must successfully connect you to your mailbox. To do this, it consults several sources of information for "clues" to connecting:

  • Is GroupWise code in memory?

  • Command-line options on the shortcut

  • The registered network provider

  • Novell eDirectory

  • The Windows Registry

  • Domain name service

  • User data entered in a login dialog box

The preceding list includes the order in which the client consults them. The following section walks through the login process.

Is GroupWise Code in Memory?

If a GroupWise component, such as Notify or the address book, is currently running, that component has already connected with your mailbox. The GroupWise client will use that same connection. Sometimes you might quit GroupWise and then try specifying a command-line option, only to get connected the same way you connected last time. This occurs because GroupWise was still unloading when you launched it again. Some code portions were still in memory, so it used the old connection.

Command-Line Options on The Shortcut

There are several command-line options you can enter on the GroupWise shortcut. These should be used as troubleshooting tools rather than administrative purposes, because they are not easy to globally administer. Figure 12.16 shows a command-line parameter that will force the GroupWise client to bring up the Login dialog box.

Figure 12.16. Using the /@U-? switch to force the GroupWise client to bring up the Login dialog box

Here are the other command-line switches that concern logging into GroupWise:

  • /@U-GroupWise user ID

  • /IPA-IP address for GroupWise POA

  • /IPP-IP port for GroupWise POA

  • /PR-Path to GroupWise remote data on local drive

  • /PC-Path to GroupWise cache data on local drive

  • /PH-Drive letter path to post office (this switch works only if the post office supports Direct mode; most do not)

During the GroupWise login process, two critical pieces of information are required. The GroupWise client needs answers to the following two questions:

  • Whose mailbox do I connect to?

  • How do I get to it?

This information can be provided via command-line options. Consider the following string:

C:\NOVELL\GroupWise\Grpwise.exe /@u-tkratzer /ipa-10.0.0.1 /ipp-1677

This string tells the GroupWise client to log in as user tkratzer, and indicates that the POA can be found on port 1677, at address 10.0.0.1.

If the /@U- switch has been set to a question mark, the client will prompt the user with the Login dialog box. This can be a useful tool for an administrator who routinely checks multiple mailboxes and wants to be prompted each time. The command-line switch to use this option is /@U-?.

The Registered Network Provider

The GroupWise client is going to make a call to the network provider. This call will return the login name that this individual used to gain access to the network.

When the GroupWise client finally connects to the POA, it will check the security level of the post office. If the PO is set to high security, the client will compare the network ID obtained with the network ID associated with the GroupWise mailbox (usually the eDirectory user ID). If these values do not match, the user will be prompted for a password.

If the security is set to high-eDirectory authentication or high-LDAP authentication, the client will allow matches only with values it knows it obtained through Novell eDirectory or LDAP. This prevents users from setting up a private network to spoof the security and hack into a GroupWise mailbox.

Novell eDirectory

The GroupWise client already consulted with Windows to see who the user was logged in as. With the login information in hand, the GroupWise client knows what kind of a network the user logged in to. If it detects eDirectory, the GroupWise client will attempt to discover GroupWise post office information from the eDirectory user object for this user.

This is the power of eDirectory at work. The eDirectory user object is associated with a post office object (from the GroupWise Account property page of the user object). That post office object has two attributes for the GroupWise client to check:

  • Access mode

  • Location

If the access mode is set to direct access, the client will connect directly to the location (UNC path) specified.

If the access mode is set to client/server only or client/server and direct, the GroupWise client will browse to the POA object, which is a child object of the PO object. That object will have one attribute for the GroupWise client to check, the network address, which will provide the GroupWise client with the IP address and port of the POA so that a client/server connection can be established.

This might seem very involved, but it is extremely fast. The Novell client for the Windows 32-bit platforms will have already pulled down most of the required information regarding the user object. If the PO object exists in the same physical partition as the user, or if the partition it is in is on the same server the user authenticated to, the discovery will take place in a fraction of a second.

The Windows Registry

Suppose that nothing is on the command line, and the NetWare client either is not logged in or is not even installed on the Windows machine. The client will now check the Windows Registry at the following key:

[HKEY_CURRENT_USER\Software\Novell\GroupWise\Login Parameters]

There are several possible parameters to be found under this key. If you were to export the entire key for a particular user, you would see something like the following:

[HKEY_CURRENT_USER\Software\Novell\GroupWise
\Login Parameters\Account Name]
@="tkratzer"

[HKEY_CURRENT_USER\Software\Novell\GroupWise\Login Parameters\Mode]
@="Master"

[HKEY_CURRENT_USER\Software\Novell\GroupWise
\Login Parameters\Path To Remote Database]
@="c:\\gwremote"

[HKEY_CURRENT_USER\Software\Novell\GroupWise
\Login Parameters\PostOfficePath]
@=""

[HKEY_CURRENT_USER\Software\Novell\GroupWise
\Login Parameters\TCP/IP Address]
@="10.0.0.1"

[HKEY_CURRENT_USER\Software\Novell\GroupWise
\Login Parameters\TCP/IP Port]
@="1677"

In each of these lines, the value in quotation marks after the @ sign is the parameter value. In the preceding example, user tkratzer will be connected to the POA at 10.0.0.1:1677. If this address and port are not accessible, the GroupWise client will look for an IP address and port defined at this location in the Windows Registry:

[HKEY_LOCAL_MACHINE\Software\Novell\GroupWise
\Client\5.0\DefaultIPAddress] @=151.155.1.2
[HKEY_LOCAL_MACHINE\Software\Novell\GroupWise
\Client\5.0\DefaultIPPort] @=1677

These two keys are created if the following has been defined in the SETUP.CFG file:

DefaultIPAddress=<x.x.x.x>
DefaultIPPort=<xxxx>

So, using the previous example, if the GroupWise client is not able to connect to 10.0.0.1:1677, because the DefaultIPAddress and DefaultIPPort are defined in the Registry, the client will go to 151.155.1.1:1677 and try to connect. This allows you to specify where you would like the GroupWise client to go in order to connect. Also remember that the 151.155.1.2 class address does not necessarily have to be this user's particular POA. When a POA gets a login request for a user, if this user is not owned by the POA, it will redirect the client to the user's owning post office.

Tip

The DefaultIPAddress can be a DNS entry as well; the client will read either an IP address or a DNS entered here.

If neither of these network connections is available, tkratzer will be connected to his remote database at c:\gwremote. The PostOfficePath parameter is blank because tkratzer's post office allows only client/server connections. A UNC path or drive mapping here is impossible.

These Registry entries were written the last time the GroupWise client connected to a mailbox. The implication here should be obvious: If you can get the client to connect once, it will "remember" how it did it when the time comes to connect again.

As previously mentioned, you can use the SETUP.CFG file to define two IP addresses in the Windows Registry that the GroupWise client will also read. These keys are listed here:

IPAddress=<x.x.x.x>
IPPort=<xxxx>
DefaultIPAddress=<x.x.x.x>
DefaultIPPort=<xxx>

Tip

If the Windows Registry already contains the IPAddress and IPPort values, the values in the SETUP.CFG file will not overwrite these settings.

Domain Name Service

Now suppose that there are no command-line switches, network information, or Windows Registry information for the GroupWise client to use. In this case, the client will still not have discovered which post office to connect to.

At this point, the client falls back on DNS. The GroupWise client will perform a DNS lookup for a server named NGWNAMESERVER first, and then if that fails, it looks for a server named NGWNAMESERVER2. If the administrator has assigned that DNS name to a valid GroupWise POA (any POA on the system), the GroupWise client will connect to that POA at the port 1677.

Tip

The POA that the DNS server points to as NGWNAMESERVER must be configured to listen at port 1677.

Note

The GroupWise client will not try to resolve NGWNAMESERVER if the DefaultIPAddress and DefaultIPPort Registry keys are present and contain an IP or DNS address and port. As stated, NGWNAMESERVER is queried only if there is no information in the Registry about where the client should go to connect.

NGWNAMESERVER Redirection

Now, suppose that this POA is not the right one for this user. On a large system, the odds are good that it will not be. In this case, the POA will ask the client who it is logging in as and then will look in the address book. The POA will then check the redirection table to find the IP address for the user's correct POA.

The user will be automatically redirected to the correct POA. Assuming reasonable network performance, this will happen in just a few seconds.

Tip

The same redirection concept is true for the DefaultIPAddress and DefaultIPPort values that you can specify in the Registry. In reality, the purpose of using the DefaultIPAddress and DefaultIPPort Registry settings is so that an administrator can tell the GroupWise client where to go to find one POA object in the GroupWise system. This, in essence, replaces the need for NGWNAMESERVER. This is why NGWNAMESERVER is not queried when the DefaultIPAddress and DefaultIPPort values are present.

Prompting the User

Suppose, though, that the administrator has been lax in his responsibilities. Not only are eDirectory and LDAP authentication not available, but the domain name service has not been configured either. The NGWNAMESERVER lookup will timeout (after a minute or so, which will be very long and painful for an impatient user), and then the user will see the screen shown in Figure 12.17.

Figure 12.17. The GroupWise Client login dialog box

This is a disaster. Take a look at the number of fields the lucky user gets to populate. Do you suppose this user will populate these correctly? Not likely. The user will pick up the phone and call you.

You can provide the user with this information automatically in at least four ways before it comes to this point, and this chapter covered each of those ways. The next section walks you through the process of covering all of your bases, ensuring that users with new machines or toasted Registries do not need to make that phone call.


Administering the Login Process

This section teaches you how to ensure that the GroupWise client can get the necessary login parameters through Novell Directory Services or the DNS. This section also discusses Registry entries to "push" to workstations, should you happen to be using a tool such as Novell ZENworks.

Configuring eDirectory

All users of a GroupWise post office should have browse, read, and compare rights to the post office object itself, as well as to the POA associated with that post office. (However, if you are using LDAP authentication, your users do not need these rights.) For simplicity, assign the rights to the post office object, and the POA object to the OU or OUs in which the users for the post office reside.

The following steps provide you with the tools to verify access modes and IP addresses when configuring eDirectory:

1. | Open the Post Office Settings page for the post office object associated with the users whose GroupWise login you are administering. The Post Office Settings property page for a post office object allows you to check on the access mode, among other things.
2. | Verify that the Access Mode field reads Client/Server Only and not Client/Server and Direct. Client/server access to mailboxes is much preferred over direct access.
3. | Verify that the UNC path to this post office is correct on the Identification property page. This is not a big issue if you are running in client/server mode, but it is still good to be accurate here.
4. | Make sure that Disable Logins is not checked. This option should be checked only if, for some reason, you want to keep users out of their mailboxes temporarily.
5. | Close the details for the PO.
6. | Open the Identification property page for the POA associated with this PO.
7. | Go to the TCP/IP Address field and verify that the TCP/IP address and port are accurate. Tip For NetWare, you might need to go to the server console and type CONFIG to view the actual IP address of the server. At a Linux server in a terminal session, you would type the command IFCONFIG. From NT/2000, you can open a DOS window and type IPCONFIG to get the IP address of the NT/2000 server.
8. | Close the POA object.

In these eight steps, you have accomplished two tasks:

  • You ensured that the GroupWise client can get login parameters from eDirectory.

  • You ensured that those parameters are accurate.

Tip

You can easily display the IP address and port for each POA object in the system by adding these columns to the POA view. Simply highlight a POA object, and then go to Tools, Edit Columns. From there, you can add columns that apply to the POA object. Select the IP address and port, and you will see every IP address and port for all your POA objects in the GroupWise system. You can also do the same thing for the UNC path. You must have the post office object highlighted when adding columns for the UNC path.

Configuring DNS

Now you need to choose a POA, preferably one that is centrally located on the LAN, to serve as the NGWNAMESERVER agent. On very large systems, it might be advisable to create a dummy post office (no users) with a POA dedicated to NGWNAMESERVER redirection. This is accomplished by following these steps:

1. | Make sure that this POA is listening on port 1677. This is done from the Network Address field of the POA's Agent Settings property page.
2. | Create a DNS record on your domain name server. This server is not part of the GroupWise system and can be on almost any server platform, including NetWare 4, 5, or 6, Windows server platforms, or any flavor of UNIX or Linux.
3. | In your DNS server, enter the hostname as NGWNAMESERVER.
4. | Enter the IP address of the POA that you chose to act as NGWNAMESERVER.

In these four steps, you have ensured that any GroupWise client that looks for NGWNAMESERVER on your system will find a POA at the IP address specified. That POA will then redirect the client to the correct POA for connection to the user's mailbox.


Administering GroupWise Client Options

The GroupWise administrator snap-ins for ConsoleOne provide you with a powerful tool for controlling the way the GroupWise client works. You can find client options by selecting a domain, post office, or user, and then choosing Tools, GroupWise Utilities, Client Options.

After selecting Environment, you see the dialog box shown in Figure 12.18.

Figure 12.18. Administering GroupWise client environment options in ConsoleOne

Some of the options in this window are also available in the GroupWise client. Take note, however, of the set of padlock buttons on the right side, as well as several other options.

You can change any setting listed in this dialog box, which will effectively change the default options for users who have not changed their defaults. By clicking the adjacent padlock, you can also lock a setting in place. This will prevent users from changing individual defaults, and it will also force the setting on users who might have already changed it.

As noted in Chapter 3, "Understanding the GroupWise Directory," GroupWise administration writes changes directly to the GroupWise domain database to which it is connected. For client options to take effect, however, the changes must propagate all the way down to the GroupWise user database, USER xxx.DB. The following list examines the architecture that makes this happen:

  1. The administrator makes a change to client options.

    For example, imagine that you have unchecked the box labeled Allow Shared Folder Creation and then locked that setting. In this scenario, a post office object was selected when going into Tools, GroupWise Utilities, Client Options. This means that the setting will apply to the entire post office.

  2. The GroupWise administration snap-ins write the change to the GroupWise domain database and create an administration update file to propagate this change to the post office.

  3. The message transfer agent (MTA) transmits this file to the POA.

  4. The POA administration thread writes this change to the post office database. The POA then writes the preference changes to the preferences capsule of all USER xxx.DB files in the post office.

This section explained how GroupWise client options set from ConsoleOne get to the GroupWise message store.


Comparing GroupWise Clients on Windows and Other Platforms

This chapter has focused exclusively on the GroupWise 7 32-bit client. Novell anticipates that more and more organizations will also require other client platforms, such as Linux, Apple, and web-based access to GroupWise. This section briefly evaluates each of these platforms in terms of feature parity, strengths, and weaknesses. Let's first have a look at the 32-bit Windows client and compare the other Non-Windows clients with this base level.

GroupWise 7 32-Bit Windows Client

This is still the flagship client for GroupWise. All the functionality available to any GroupWise user is typically available within this client. It requires a 32-bit Windows platform, meaning any of the following Windows versions:

  • Windows 2000 on a Pentium 200 or higher with at least 128MB of RAM

  • Windows XP Professional on a Pentium 300 or higher with at least 128MB of RAM

  • Windows 2003 on a Pentium 300 or higher with at least 128MB of RAM

You will need 60MB of free disk space to install the GroupWise Windows client.

Note

The GroupWise 7 client is officially not supported on Windows 9x or on Windows Me (but see the later section "GroupWise 6.5 32-Bit Windows Client for Windows 9x and Me" for more info about this subject).

Strengths

The primary strengths of this client lie in the fact that this is currently still the flagship client for Novell GroupWise. When new features and functionality are coded for GroupWise, they are coded for this platform first. The following list is hardly complete, but it does illustrate some of what is present (so that you can judge the other clients against this one):

  • Notification of new messages

  • Document administration features

  • Remote-access capabilities (via GroupWise remote; requires a standard installation)

  • Archive access

  • Full-featured toolbars, menus, and quick menus

  • Full collaboration features, including folder sharing, GroupWise library access, item tracking, calendar viewing, and more

Weaknesses

The primary weakness of this client lies in the fact that it must be installed to every workstation that needs to run it. The GroupWise client also takes over 60MB of disk space.

GroupWise 7 Cross-Platform Client on Linux and Apple

For Linux and Macintosh users, Novell delivers the GroupWise 7 Cross-Platform client for Linux and Apple. This client uses Java and you can run this client on any of the following desktop operating systems:

  • Novell Linux Desktop, plus the KDE desktop or the GNOME desktop

  • Red Hat Desktop 4 or Red Hat Enterprise Linux WS 4, plus the GNOME desktop

  • Macintosh OS 10.3 (Panther) or Macintosh OS 10.4 (Tiger)

You will need Java Virtual Machine (JVM) 1.4.2 or later and at least 40MB of free disk space to install the GroupWise Cross-Platform client.

Installing and Running the Cross-Platform Client on Linux

The installation of the Cross-Platform client on Linux is pretty simple: Much like the NetWare/Windows SDD, the file set for Linux contains a CLIENT folder with a LINUX subfolder. This folder contains an install script and two installable packages called RPMs, one for the GroupWise client and one for GWCheck. There is also an INSTALL script in the root of the Linux CD/DVD, which allows you to install every GroupWise component on Linux. Make sure you meet the requirements mentioned previously and follow these installation instructions:

1. | In a new terminal window, become root by entering su and the root password.
2. | Change to the root of the GroupWise 7 (Linux/Mac) CD or SDD.
3. | Enter ./install.
4. | In the graphical interface select the Install Products option and select Install GroupWise Client.

The GroupWise Client will be installed to /opt/novell/groupwise/client. You can also install the Cross-Platform client by changing to the client/linux folder on the GroupWise 7 Client (Linux/Mac) CD, then running the RPM. After the installation finishes, you can start the client by following these instructions:

1. | Use the icon on the desktop OR at the command line, change to the /opt/novell/groupwise/client/bin folder.
2. | Enter ./groupwise.sh.

You will be prompted for a username, password, IP address, and IP port number of your post office agent, as shown in Figure 12.19.

Figure 12.19. The GroupWise Cross-Platform Client login screen

After the login, you will see the familiar Group Wise main window and will be able to use the many new features.

Installing and Running the Cross-Platform Client on Apple

To instal l the GroupWise Cross-Platform client on Apple Macintosh, make sure you meet the requirements mentioned previously and follow these instructions to install the client:

  • Browse to the GroupWise.app.sit file on the GroupWise 7 Client (Linux/Mac) CD.

  • Double-click the GroupWise.dmg file to install the Cross-Platform client software.

The installation process adds a GroupWise Cross-Platform client icon to your desktop. You can start the Cross-Platform client on Apple Macintosh by double-clicking the icon on the desktop.

Strengths

There was an earlier GroupWise 6.5 version of the Cross-Platform client, but the new GroupWise 7 version has a lot of additional features and is getting closer and closer to the Windows 32-bit client. Here are some of the new features:

  • Support for All Day Events

  • New default Compose and Read View Fonts and Reply Text Format

  • Capability for GroupWise Check (GWCheck) to be used both on Linux and on Apple

  • Support for Rules and Filters

  • Support for Spell Checker and spell checking as you type

  • Support for the Junk Mail Handling features

  • Support for GroupWise Backup and Restore features

Weaknesses

Currently the Windows 32-bit client still has more features than the Cross-Platform client, quite often because the missing functions are heavily tied to the underlying Windows platform. For example, GroupWise Document Management System (DMS) relies heavily on the ODMA standard, but the external taskforce responsible for ODMA has not been able yet to create a (fully) developed interface for Linux or Apple.

Evolution Connection to GroupWise 7

Evolution is the most popular tool on Linux to provide integrated mail, address book, and calendaring functionality. Evolution was developed by Ximian, now part of the Novell Corporation, and is included in most of the popular Linux distributions. Evolution is quite often called the Outlook of the Linux desktop and is of course included in the Novell Linux Desktop (NLD) as well. With GroupWise 7 any Evolution 2.x client will now be able to connect to the new SOAP interface, which is part of the GroupWise 7 post office agent (POA).

Strengths

The new SOAP interface is an important part of the new direction to open up GroupWise to developers, not only for Evolution, but also, for example, for PDA synchronization solutions. As such, Novell will be very committed to further improving and enhancing this interface, enabling full support for developments on any platform, including, of course, the very important Linux platform.

Even though Evolution is a community project, many former Ximian employees are now Novell employees. The Ximian employees are involved in both enhancing Evolution and making sure that the SOAP interface in GroupWise will be able to deliver the necessary functionality.

Weaknesses

At the moment of writing this book, Evolution already connected very well to the new GroupWise 7 SOAP interface in the POA, and most Evolution features were implemented. Because of limitations on both sides, the feature mapping was not 100% complete yet, but in the near future we can probably expect some rapid improvements.

GroupWise Connector for Outlook

Outlook is still a very popular email client on the Windows platform, and the new GroupWise 7 Windows 32-bit client is certainly a very serious alternative for Outlook. However, in too many cases there are practical reasons to (temporarily) keep using Outlook. For example, imagine a larger environment with 25,000 users in many locations moving away from Exchange 5.5 and Outlook XP to GroupWise 7. Even with great tools like ZENworks, it would be a huge challenge to deploy the GroupWise 7 client to all of these desktops.

For this and other scenarios Novell has created the GroupWise Connector for Outlook, a complete redesign when compared to earlier projects. All the following desktop operating systems are compatible with the GroupWise Connector for Outlook:

  • Windows 2000 on a Pentium 200 or higher with at least 128MB of RAM

  • Windows XP on a Pentium 300 or higher with at least 128MB of RAM

  • Windows 2003 on a Pentium 300 or higher with at least 128MB of RAM

You will need to use Microsoft Outlook XP/2003; older versions of Outlook are not supported due to several limitations in these versions.

Installing and Running the GroupWise Connector for Outlook

To install the GroupWise Connector for Outlook, make sure you meet the requirements mentioned previously and follow these instructions to install the client:

1. | On the GroupWise 7 CD/DVD or SDD, go to the CLIENT folder and then select the CONNECTOR folder.
2. | Double-click the setup.exe file and follow the onscreen instructions to install the GroupWise Connector for Outlook.

After installing the GroupWise Connector for Outlook, if you start Outlook, your GroupWise account should automatically appear in the login screen. If it does not appear, you might need to fill in some details, such as username, password, post office agent address, and the post office agent port number. In some cases you might like to create a GroupWise account in Outlook; here are the instructions for doing this:

1. | Start the Microsoft Outlook client and select Tools, E-mail Accounts.
2. | Select Add a New E-mail Account, then click Next.
3. | Select Additional Server Type, and then click Next.
4. | Select Novell GroupWise, and then select Next.
5. | Type the name or TCP/IP address and the port number of your GroupWise server.
6. | Type your GroupWise username and click Finish.

You should now be able to use Outlook connected to the GroupWise back end using the GroupWise Connector for Outlook.

Strengths

With this new connector most "normal" Outlook users will be able to work as they used to work connected to the Exchange server, but will immediately benefit from the higher availability and the more robust GroupWise back end. Almost any feature will work as expected, and if needed, users can be gradually upgraded from the Outlook client to the GroupWise 7 client to allow them to use even more GroupWise specific features, if needed.

Weaknesses

With Outlook, one of the concerns will be that the Outlook client itself is more vulnerable to hacks and viruses. If a virus accidentally slips through your protection system, it might not hurt your GroupWise back end or GroupWise clients, but it might still have an impact on these Outlook users. This is, of course, due to the nature and the architecture of both solutions. For the same reason, not all features could be mapped. Here is a list of things that are currently not supported:

  • Journals do not exist in GroupWise. You can still create Journals in Outlook, but they will be visible only to this user.

  • Because public folders are not supported in the GroupWise Connector for Outlook, the Find Public Folders item on the Tools menu has been removed. Shared folders provide similar functionality to public folders for sharing items with other users.

  • GroupWise handles junk mail differently from Outlook. If you have set up Junk Mail Handling in GroupWise, a Junk Mail folder appears in the folder list, but it doesn't have access to GroupWise junk mail functionality. To handle junk mail in the GroupWise Connector for Outlook, the user should use the default Outlook junk mail system.

  • Outlook and GroupWise use different default categories. Because of this, if you move from the GroupWise Connector for Outlook to a GroupWise client, your categories in the GroupWise Connector for Outlook are not preserved in the GroupWise client.

  • When you're creating a delegate, there are a few differences in the settings. In Outlook, you can specify whether you want a delegate to receive copies of meeting-related messages sent to you. You can also specify whether you want Outlook to automatically send a message to a delegate summarizing these permissions. In Outlook, you can specify whether you want the delegate to see your private items. In the GroupWise Connector, you do not have these options.

  • In Outlook, you can specify to send meeting requests and responses only to your delegates, and not to you. In the GroupWise Connector for Outlook, you do not have this option. Meetings are automatically sent to you and not your delegates. Your delegate can view your calendar or mailbox if you have assigned these rights to your delegate.

  • Proxy is specific to GroupWise and does not exist in Outlook. In GroupWise, you use Proxy to manage another user's mailbox and calendar. Proxy lets you perform various actions, such as reading, accepting, and declining items on behalf of another user within the restrictions the other user sets.

Even though these more "advanced" options are not available (yet), the GroupWise Connector for GroupWise 7 has already attracted a lot of attention and approval.

GroupWise 6.5 32-Bit Windows Client for Windows 9x and Me

Because of the many changes in the way GroupWise installs with MSI, as described earlier in this chapter, as well as because of weaknesses in the Windows 9x graphical libraries (for example, high-resolution icons did not work properly), like many other vendors Novell has decided not to include support for the GroupWise 7 client on Windows 9x and Windows Me. The good news is, however, that the GroupWise 6.5 32-bit Windows client will still work against a GroupWise 7 post office in client/server mode.

Strengths

Here are the strengths for using the GroupWise 6.5 32-bit Windows client on Windows 9x and Me:

  • The GroupWise 6.5 client was already a very rich Windows client, and many users on these older workstations might not need all the newer GroupWise 7 features.

  • Some of the new GroupWise 7 features are in the back end and will be therefore apply to these users as well.

Weaknesses

Some features will be visible in the GroupWise 6.5 client as well, but in a different fashion. For example, the GroupWise 7 multiple layered calendar support allows you to created shared calendars, which in the GroupWise 7 client will just be one layer in the normal calendar view. In GroupWise 6.5 the user can accept such a shared calendar and will be able to view it as a separate "normal" shared calendar folder, but of course not as part of the layered calendar view. If this user later switches to the new GroupWise 7 client, these folders will stay "normal" shared folders and cannot be (easily) integrated into the new layered calendar view.

GroupWise 7 WebAccess Full-Featured Browser Support

Novell has long been touting the standards-based web platform as the future alternative platform for GroupWise. If the 32-bit Windows client won't work for you, any machine that can run a supported web browser can access a GroupWise mailbox through the WebAccess gateway. And with GroupWise 7 we've seen many enhancements to this important WebAccess interface, so it has become even more usable with more features and a new look and feel. New features include the following:

  • New look and feel reminiscent of the Windows client

  • Drag-and-drop functionality to easily move items between folders

  • Right-click context-sensitive drop-down menus on Mailbox and Calendar items for easy access to commonly used features (for example, Open, Reply, Forward, Accept, Decline, Delete, and so on)

  • Enhanced item properties (including delivery status, send options, and Junk Mail Handling results) and Mark Read item action

  • Automatic name completion from your Frequent Contacts Address Book

  • Folder management, so that you can rearrange the folders in your folder list, add and delete folders, and share folders more easily

  • Work in Progress folder, so that items you save in your Work in Progress folder in the Windows client or Cross-Platform client are available to you in the WebAccess client

  • Quick Find feature for fast full-text searches through your mailbox without setting Advanced Find options

  • In-line Calendar appointments, tasks, and notes, and posted Calendar appointments, tasks, and notes

You can find more information about WebAccess in Chapter 11, "Installing and Configuring GroupWise WebAccess."

Strengths

WebAccess with full-featured browser support has several strong features:

  • No installation required. Any Java-compliant web browser can serve as the GroupWise client.

  • Low bandwidth. This client will perform acceptably over a dial-up connection.

  • Wide cross-platform support. This client performs the same on Windows, Macintosh, UNIX, and Linux workstations.

  • Support for SSL connections that ensures security for mailbox access across the Internet.

Weaknesses

This platform also has its weaknesses:

  • No notification of new messages, although third parties like Omni offer solutions for this (www.omni-ts.com)

  • No offline support

  • No archive access

GroupWise 7 WebAccess/Wireless Simple HTML Browser Support Usable for PDA and Phones

The advent of handheld computers has brought back the need for simple HTML support, the stuff GroupWise WebAccess was made of, long ago. So, for example, a Pocket PC platform device can access GroupWise 7 WebAccess. The interface is simpler and leaner, specifically for the popular handheld computer platforms. Figure 12.20 shows the GroupWise 7 WebAccess simple HTML browser support interface.

Figure 12.20. GroupWise 7 WebAccess with simple HTML support

Strengths

This platform's primary strength is its very broad device support. WebAccess with simple HTML browser support has several strong features:

  • No installation required. Any Mozilla 4.xcompatible browser or better can support this version of WebAccess.

  • Low bandwidth. This client will perform acceptably over a dial-up connection.

  • Wide cross-platform support.

  • Support for SSL connections that ensures security for mailbox access across the Internet.

Weaknesses

Most wireless clients can read messages, but not attachments, and you can compose simple messages. The weaknesses are not really in GroupWise wireless, but in the devices themselves. This platform also some other weaknesses:

  • No notification of new messages

  • No offline support

  • No archive access

Tip

Third parties like Omni offer PDA synchronization solutions that use the WebAccess framework and enhance it to enable it to function as a synchronization server. You can find more information at www.omni-ts.com.

GroupWise Internet Agent POP3/IMAP4

Some of your users might want to access their GroupWise email from home, using their Eudora, Netscape Mail, or Outlook Express mailers. Any mail application that supports POP3 or IMAP4 mail access can collect GroupWise email through a correctly configured GroupWise Internet agent. There are POP3 clients for almost any platform, including the very popular Palm OS devices.

Note

Chapter 10, "Installing and Configuring the GroupWise Internet Agent," talks more about where to configure POP3 and IMAP4 functionality on the GroupWise Internet agent. You can also enable IMAP on your POA, as described in Chapter 8.

Strengths

Following are the strengths for this support:

  • Low user-education costs (users use the tool they are familiar with)

  • Low bandwidth

  • Mailbox that can be used offline (POP3 only)

  • Wide cross-platform support

Weaknesses

This configuration has some weaknesses:

  • Limited collaboration support; all items show up only as email items on the POP3 or IMAP4 mail application

  • No archive access

  • No GroupWise library access


Summary

This chapter explained the process of deploying the GroupWise client and administering it. This chapter also introduced the wide variety of platforms and formats that a GroupWise mailbox can access. If you need even more up-to-date information on upgrading the GroupWise client, see the GroupWise 7 Upgrade Guide available at http://www.caledonia.net.


Part IV: Practical Administration

13 Moving Users

14 Working with GroupWise Agents on the Linux Platform

15 Administering Multiple GroupWise Systems

16 Internet Addressing

17 Maintaining the GroupWise System

18 Monitoring Your GroupWise System Through GroupWise


Chapter 13. Moving Users

A casual survey of GroupWise administrators will reveal that moving users is one of the more problematic tasks they perform. This chapter exposes the architecture behind user moves and presents ways to avoid problems when moving users. This chapter also walks you through the process and explores ways to troubleshoot user moves that have gone wrong.

The superstitious reader might associate ill omens with the fact that the move-user process is discussed in Chapter 13. Although we cannot refute such superstitions, we can assure you that it was not some sort of evil coincidence that this topic ended up in Chapter 13. We did it deliberately...


Understanding the Directory-Level Move of a GroupWise User Object

A GroupWise move-user operation is both a GroupWise directory operation and a message-store operation. This section explores what happens in the GroupWise directory when a user object is moved from one post office to the next.

Moving a user is actually called a rename by the GroupWise directory processes. The following POA log from the destination post office shows when a user named BSmith is moved from one post office to the next:

ADM: Completed: Rename object in Post Office
 - User DOMAIN2.PO2.BSMITH (Administrator: (WWW_TREE)
tkratzer.www.americas, Domain: DOMAIN1)

The directory-level move of a GroupWise object rarely fails. If you make sure that you connect to the destination domain when you perform the move, you will further reduce the likelihood of problems.

In a move-user operation, the owning domain, as explained in Chapter 3, "Understanding the GroupWise Directory," isn't readily apparent as in most operations. In a move-user operation in which a user is moved from DOMAIN1.PO1 to DOMAIN2.PO2, the destination domain immediately becomes the owning domain. This means that the destination domain must approve the move/rename operation before anything else will happen. The most important directory processes in a move-user operation are the ones at the destination domain and the destination post office. To ensure a smooth move-user operation at the GroupWise directory level, an administrator should be connected to the destination domain's WPDOMAIN.DB database before issuing the move of the user.

Determining When a Move Is Pending

When you move a user, eDirectory is updated with the object's post office change, but the GroupWise directory might still be propagating the change. If eDirectory reports that the user's post office is PO2, but the GroupWise directory reports that the user's post office is PO1, the GroupWise snap-in will know that a move is pending. Or if eDirectory reports that a user's post office is still PO1, but the GroupWise directory reports that it's PO2, the GroupWise snap-in will think that a move is pending.

This condition will exist until the GroupWise directory has successfully broadcast the user move to all other domains. This condition can exist also when the eDirectory replica that you made changes to when moving the user is not the same replica that ConsoleOne is talking to at a certain moment. Until this condition no longer exists, the GroupWise directory is in a freeze state regarding the user's object. If you attempt to view the details or edit this user's object while in this freeze state, you will see the message shown in Figure 13.1.

Figure 13.1. The pending move warning

This freeze state can be a two-edged sword at times. It sometimes means that the GroupWise directory is waiting to catch up to the eDirectory. Generally, however, it means that eDirectory is behind the GroupWise directory. Follow this fictitious scenario with the following players for an explanation of how this happens:

  • USERA, a user on DOMAINA

  • DOMAINA

  • DOMAINB

  • eDirectory called PARTITION-A-REPLICA-1

  • eDirectory called PARTITION-A-REPLICA-2

Following is an explanation of how GroupWise and eDirectory can get out of sync during a GroupWise user move:

  1. The state of the system at the directory level is as described here:

    • The GroupWise administrator is connected to DOMAINB.

    • The NetWare client is communicating with the eDirectory PARTITION-A-REPLICA-1.

  2. The GroupWise administrator moves USERA to DOMAINB.

  3. The immediate state of the system at the directory level becomes this:

    • DOMAINB is the destination domain on the move operation, so DOMAINB approves the move operation.

    • eDirectory PARTITION-A-REPLICA-1 knows about the change to USERA's post office.

    • DOMAINA doesn't know about the change to USERA yet; it's still replicating.

    • eDirectory PARTITION-A-REPLICA-2 is not aware of the change to USERA; it hasn't synced with eDirectory PARTITION-A-REPLICA-1 yet.

  4. The error state is as described here:

    • Another administrator, authenticated to eDirectory PARTITION-A-REPLICA-2, launches GroupWise administrator.

    • The GroupWise administrator is connected to DOMAINB.

    • The NetWare client is communicating with eDirectory PARTITION-A-REPLICA-2.

    • eDirectory PARTITION-A-REPLICA-2 hasn't received the change from eDirectory PARTITION-A-REPLICA-1.

Now a condition exists in which there is a post office mismatch between GroupWise and eDirectory. The result is that the administrator will continue to get the "Pending move" message shown in Figure 13.1.

Generally, this condition will rectify itself with time. Sometimes it doesn't, though. In this case, you will have to do something to clean up the directory. For example, you could delete the user's eDirectory account. You could also try removing the link between GroupWise and eDirectory, which is called disassociating GroupWise attributes. This option is in ConsoleOne under Tools, GroupWise Utilities, GW/eDirectory Association.

Understanding the Chronology of the Move-User Process

The following is an investigation into how a user is moved. The user, USERA, is being moved from the SOURCE post office to the DESTINATION post office. The entire move-user process at both the directory level and the message-store level is mapped out in this section.

The GroupWise 6.x and 7 post office agents (POAs) support a much faster move-user method than older versions of GroupWise. The method of moving a user's message store is called a live move. The slower move method is called a message-file move or a batch move. This chapter explains only the live move process.

The GroupWise message-file move is the old standby architecture for a move-user operation. GroupWise POAs prefer to use live move, and will attempt to use the live move architecture first. POAs use the message-file move method only when one of the following conditions exists:

  • Either post office object has the Disable Live Move check box checked under the Post Office Settings property page.

  • One POA cannot contact the other via its TCP/IP address and/or client/server port.

  • Either POA is version 5.5.x or older.

  • You attempt to bring down the source POA while a live move is in process.

Moving a GroupWise User via Live Move

When performing this move, GroupWise Administration is connected to the WPDOMAIN.DB for the destination domain, DOMAIN2. Table 13.1 lays out the scenario details for this sample user move.

Table 13.1. Live User Move Scenario Details

SOURCE

POST OFFICE

POA IP ADDRESS AND PORT

DOMAIN

PO1

137.65.55.211:1678

DOMAIN1

Destination

POST OFFICE

POA IP ADDRESS AND PORT

DOMAIN

PO2

137.65.55.211:1677

DOMAIN2

Tip

If the user will be moving to a new domain, make sure you're connected to the new domain when issuing the move-user operation.

Tip

To show the detail in the GroupWise POA logs as shown in this sample scenario, your POAs must have their logging level set to verbose.

Following is an explanation of a user move scenario in which a file-based/batch move mechanism is used:

  1. In ConsoleOne, the GroupWise administrator is connected to DOMAIN2 and moves USERA to DOMAIN2.PO2.

    The MTA for DOMAIN2 broadcasts the USERA move to PO2. PO2's POA must approve the rename of USERA.PO1.DOMAIN1 to USERA.PO2.DOMAIN2.

Note

DOMAIN2 does not broadcast the USERA move operation to the rest of the GroupWise system yet.

  2. PO2 receives the USERA rename and the ADMIN tHRead of the POA updates its WPHOST.DB file with the USERA "rename" operation. Also note that POA reports that the user ADMIN.AMERICAS is the person who performed the rename operation.

    The ADMIN tHRead of the POA creates a message to be sent back to its domain, DOMAIN2, indicating that PO2 received and approved the rename of USERA.

    WWWFS1\SYS:/PO2\wpcsout\ofs\2\a2b917b5.001, Size: 1746
07:48:05 2A4 Processing a2b917b5.001
07:48:05 2A4 Processed OK
07:48:06 278 ADM: Completed: Rename object in post office
User CORP.PO1.USERA (Administrator: (WWW_TREE)
admin.americas, Domain: CORP)
07:48:12 294 MTP: Sender thread started for link CORP: 4 running
07:48:12 294 MTP: Sender thread started for link CORP: 5 running
07:48:12 3BB MTP: CORP: Connection established: 137.65.55.211
07:48:12 3BB MTP: File sent: A2B917B6.001 Queue: 2 Size: 2014
07:48:12 3B9 MTP: CORP: Connection established: 137.65.55.211
07:48:12 3A9 MTP: CORP: Connection established: 137.65.55.211
07:48:12 3B9 MTP: File sent: A2B917B6.005 Queue: 2 Size: 746
07:48:12 3A9 MTP: File sent: A2B917B6.003 Queue: 2 Size: 1654

  3. DOMAIN2 receives the message from PO2 indicating an all-systems-go on the move-user operation.

    DOMAIN2 broadcasts the rename of USERA to the entire GroupWise system by sending the rename operation to the primary domain and to all the post offices in DOMAIN2. DOMAIN2 also sends a few messages down to the destination post office that contains the client option settings for the user, which are merged into the user database. At this point the USER xxx.db exists on the destination post office.

  4. DOMAIN1 receives the message from the primary domain indicating the rename of USERA.

    DOMAIN1's MTA-ADMIN thread updates the WPDOMAIN.DB file with the rename of USERA. DOMAIN1's MTA transmits the rename of USERA to PO1.

  5. PO1 receives the USERA rename operation.

    PO1's POA updates the WPHOST.DB file with the rename of USERA.

  6. PO2 logs into PO1 and requests an inventory list of all of USERA's mailbox items. When the inventory list is received, PO2 determines which items are already at PO2 and do not need to be requested from PO1. PO2 then stores the request for the inventory items it needs in the deferred database at PO2.

    PO2's POA log reads as shown here:

    07:48:24 288 C/S Login dos  ::GW Id=USERA :: 137.65.55.211
07:48:25 288 Remote Request From: USERA
07:48:25 288 (TRACKMOVE) BEGIN PHASE
'MvDstUser_SendRetrievalList_Begin_Live': USERA (umz)
07:48:25 288 (TRACKMOVE) (Move.)
Receiving Inventory List: USERA (umz)
07:48:25 288 (TRACKMOVE) Receiving and
storing INVENTORY list - should only happen once: USERA (umz)
07:48:25 288 Purge record 02CC
07:48:25 288 (TRACKMOVE) (Move.)
Inventory List Received (1540): USERA (umz)
07:48:25 288 (TRACKMOVE) (Move.)
Queue First Deferred Retry Message: USERA (umz)

  7. PO2 logs in again to PO1 and requests the inventory items that it needs. You will notice that the POA does a good job of giving a detailed log of just where it is in the move-user process. Also notice that after approximately every 70 inventory items received, the POA reports how many inventory items it has remaining. PO2's POA log reads as shown here:

    07:48:26 2A4 (TRACKMOVE) BEGIN PHASE
'MvDstUser_SendRetrievalList_LiveRetry': USERA (umz)
07:48:26 2A4 (TRACKMOVE) (Move.)
Requesting User Data: USERA (umz)
07:48:26 2A4 (TRACKMOVE) Attempting
'MvDstUser_SendRetrievalList': USERA (umz)
07:48:26 2A4 (TRACKMOVE) Beginning
'MvAnyUser_LiveMoveLogin': USERA (umz)
07:48:26 2A4 (TRACKMOVE) Attempting connection
'MvAnyUser_LiveMoveLogin' to 137.65.55.211:1678: USERA (umz)
07:48:26 2A4 (TRACKMOVE) Establish Transfer LIVE: USERA (umz)
07:48:26 2A4 (TRACKMOVE) (Move.)
Remaining Inventory Count (1540): USERA (umz)
07:48:26 2A4 (TRACKMOVE) BEGIN LIVE
'MvDstUser_SendRetrievalList_LiveDispatch': USERA (umz)
07:48:26 2A4 (TRACKMOVE) Continue LIVE
'MvDstUser_SendRetrievalList_LiveDispatch'
(1 0x00000001): USERA (umz)
07:48:26 2A4 (TRACKMOVE) (Move.) Folder Received: USERA (umz)
07:48:26 2A4 (TRACKMOVE) (Move.) Folder Received: USERA (umz)
07:48:26 2A4 (TRACKMOVE) (Move.) Folder Received: USERA (umz)
<<Several Lines Omitted>>
07:48:27 2A4 (TRACKMOVE) (Move.) Bag Record Received: USERA (umz)
07:48:27 2A4 (TRACKMOVE) (Move.) Bag Record Received: USERA (umz)
07:48:27 2A4 (TRACKMOVE) (Move.) Bag Record Received: USERA (umz)
<<Several Lines Omitted>>
07:48:27 2A4 (TRACKMOVE) (Move.)
Category Record Received: USERA (umz)
07:48:27 2A4 (TRACKMOVE) (Move.)
Category Record Received: USERA (umz)
<<Several Lines Omitted>>
07:48:27 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
07:48:27 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
07:48:27 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
<<Several Lines Omitted>>
07:48:27 2A4 (TRACKMOVE) (Move.)
Remaining Inventory Count (1443): USERA (umz)
07:48:27 2A4 (TRACKMOVE) Continue LIVE
'MvDstUser_SendRetrievalList_LiveDispatch' (2 0x00000002):
USERA (umz)
07:48:28 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
<<Several Lines Omitted>>
07:48:28 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
07:48:28 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
07:48:28 2A4 (TRACKMOVE) (Move.)
Remaining Inventory Count (1372): USERA (umz)
07:48:28 2A4 (TRACKMOVE) Continue LIVE
'MvDstUser_SendRetrievalList_LiveDispatch' (3 0x00000003):
USERA (umz)
<<Over Seven Hundred Lines Omitted>>
07:48:41 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
07:48:41 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
07:48:41 2A4 (TRACKMOVE) (Move.)
Remaining Inventory Count (533): USERA (umz)
07:48:41 2A4 (TRACKMOVE) Continue LIVE
'MvDstUser_SendRetrievalList_LiveDispatch' (15 0x0000000f):
USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.)
AddressBook Component Received: USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.)
AddressBook Component Received: USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.)
User Setting Received: USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.)
User Setting Received: USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.)
User Setting Received: USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.)
Remaining Inventory Count: USERA (umz)
07:48:49 2A4 (TRACKMOVE) END LIVE
'MvDstUser_SendRetrievalList_LiveDispatch' (0 0x00000000):
USERA (umz)
07:48:49 2A4 (TRACKMOVE) The INVENTORY
list is now EMPTY: USERA (umz)
07:48:49 2A4 (TRACKMOVE) Finished retrieval
LIVE - will be purging SOURCE database: USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.)
Transfer Complete. All Items Received: USERA (umz)
07:48:49 2A4 (TRACKMOVE) (Move.)
Sending Purge Notification: USERA (umz)
07:48:49 2A4 (TRACKMOVE) Deleting INVENTORY list
07:48:49 2A4 (TRACKMOVE) END PHASE
'MvDstUser_SendRetrievalList_LiveRetry' (0 0x00000000):
USERA (umz)
07:48:49 2A4  Processed OK
07:48:49 3A9 MTP: File sent: A2B917DA.001 Queue: 2 Size: 1462
07:48:49 3B9 MTP: File sent: A2B917DB.001 Queue: 2 Size: 1462
07:48:49 3B9 MTP: File sent: A2B917DE.001 Queue: 2 Size: 1462

  8. This step shows what is being processed on PO1 that is happening simultaneous to the actions going on in step 7. The source post office PO1 sends the user's entire inventory in batches. Each batch is numbered with the same batch number indicated in PO2's POA log.

    PO1's POA processes the live request for inventory items from PO2's POA; the log for PO1's POA reads as shown here:

    2WWWFS1\SYS:/PO1\wpcsout\ofs\2\a2b917c1.001, Size: 1738
07:48:17 397 Processing a2b917c1.001
07:48:17 397  Processed OK
07:48:18 39B ADM: Completed: Rename object in post office
User CORP.PO1.USERA (Administrator: (WWW_TREE) admin.WWW,
Domain: CORP)
07:48:22 387 MTP: Sender thread started for link CORP: 4 running
07:48:22 387 MTP: Sender thread started for link CORP: 5 running
07:48:22 3A1 MTP: CORP: Connection established: 137.65.55.211
<<A Few Lines Omitted>>
07:48:23 3B5 MTP:  Received file:
WWWFS1\SYS:/PO1\wpcsout\ofs\2\22b917c7.001, Size: 1746
07:48:23 397 Processing 22b917c7.001
07:48:23 397 Processing Admin Task: Rename
07:48:23 397 (TRACKMOVE) BEGIN PHASE
'MvSrcUser_SendInventoryList_Begin': USERA (umz)
07:48:23 397 (TRACKMOVE) (.Move) Initiating: USERA (umz)
07:48:24 397 User USERA moved, terminating current session
07:48:24 397 (TRACKMOVE)
(.Move) Queue First Deferred Retry Message: USERA (umz)
07:48:24 397 (TRACKMOVE)
Attempting 'MvSrcUser_SendInventoryList': USERA (umz)
07:48:24 397 (TRACKMOVE) Beginning 'MvAnyUser_LiveMoveLogin':
 USERA (umz)
07:48:24 397 (TRACKMOVE) Attempting connection
'MvAnyUser_LiveMoveLogin' to 137.65.55.211:1677: USERA (umz)
07:48:25 397 (TRACKMOVE) (.Move) Sending Inventory List (1540):
 USERA (umz)
07:48:25 397 (TRACKMOVE) END PHASE
'MvSrcUser_SendInventoryList_Begin' (0 0x00000000): USERA (umz)
07:48:25 397 Admin Task Completed: OK
07:48:25 397 Processed OK
07:48:26 37F***NEW PHYS. CONNECTION, Tbl Entry=0, Socket=115
07:48:26 37F***NEW APP CONNECTION, Tbl Entry=0,
Check ID=1119424940
07:48:26 37F C/S Login dos ::GW Id=USERA :: 137.65.55.211
07:48:26 37F Remote Request From: USERA
07:48:26 37F (TRACKMOVE) BEGIN PHASE
'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz)
07:48:26 37F (TRACKMOVE) (.Move) Request for User Data Received:
 USERA (umz)
07:48:26 37F (TRACKMOVE) BEGIN LIVE
'MvSrcUser_GetMovedUserBoxContent_Live' (1 0x00000001):
 USERA (umz)
07:48:26 37F (TRACKMOVE) (.Move) Folders Sent (12): USERA (umz)
07:48:26 37F (TRACKMOVE) (.Move) Bag Records Sent (25):
 USERA (umz)
07:48:26 37F (TRACKMOVE) (.Move) Category Records Sent (4):
 USERA (umz)
07:48:26 37F (TRACKMOVE) (.Move)
Remaining Inventory Count (1443): USERA (umz)
07:48:26 37F (TRACKMOVE) Continue LIVE
'MvSrcUser_GetMovedUserBoxContent_Live' (1 0x00000001):
 USERA (umz)
07:48:26 37F (TRACKMOVE) END PHASE -
'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000):
 USERA (umz)
07:48:27 37F Remote Request From: USERA
07:48:27 37F (TRACKMOVE) BEGIN PHASE -
'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz)
07:48:27 37F (TRACKMOVE) Continue LIVE
'MvSrcUser_GetMovedUserBoxContent_Live' (2 0x00000002):
 USERA (umz)
07:48:27 37F (TRACKMOVE) (.Move)
Remaining Inventory Count (1372): USERA (umz)
07:48:27 37F (TRACKMOVE) Continue LIVE
'MvSrcUser_GetMovedUserBoxContent_Live' (2 0x00000002):
 USERA (umz)
07:48:27 37F (TRACKMOVE) END PHASE -
'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000):
 USERA (umz)
07:48:28 37F Remote Request From: USERA
07:48:28 37F (TRACKMOVE) BEGIN PHASE
'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz)
07:48:28 37F (TRACKMOVE) Continue LIVE
'MvSrcUser_GetMovedUserBoxContent_Live' (3 0x00000003):
 USERA (umz)
07:48:28 37F (TRACKMOVE) (.Move)
Remaining Inventory Count (1301): USERA (umz)
07:48:28 37F (TRACKMOVE) Continue LIVE
'MvSrcUser_GetMovedUserBoxContent_Live' (3 0x00000003):
 USERA (umz)
07:48:28 37F (TRACKMOVE) END PHASE
'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000):
 USERA (umz)
07:48:29 3A7 MTP: CORP: Connection established: 137.65.55.211
07:48:29 3AD MTP: CORP: Connection established: 137.65.55.211
07:48:29 3AF MTP: CORP: Connection established: 137.65.55.211
07:48:29 3A7 MTP: File sent: A2B917C8.001 Queue: 2 Size: 886
07:48:29 3AD MTP: File sent: A2B917C8.003 Queue: 2 Size: 886
07:48:29 3AF MTP: File sent: A2B917C9.001 Queue: 2 Size: 894
07:48:29 3A7 MTP: File sent: A2B917C9.003 Queue: 2 Size: 886
07:48:29 37F Remote Request From: USERA
07:48:29 37F (TRACKMOVE) BEGIN PHASE
'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz)
07:48:29 37F (TRACKMOVE) Continue LIVE
<<Several Lines Omitted>>
07:48:47 37F (TRACKMOVE) Continue LIVE
'MvSrcUser_GetMovedUserBoxContent_Live'
(21 0x00000015): USERA (umz)
07:48:47 37F (TRACKMOVE) (.Move)
Remaining Inventory Count (46): USERA (umz)
07:48:47 37F (TRACKMOVE) Continue LIVE
'MvSrcUser_GetMovedUserBoxContent_Live'
(21 0x00000015): USERA (umz)
07:48:47 37F (TRACKMOVE) END PHASE
'MvSrcUser_GetMovedUserBoxContent_Live'
(0 0x00000000): USERA (umz)
07:48:48 37F Remote Request From: USERA
07:48:48 37F (TRACKMOVE) BEGIN PHASE
'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz)
07:48:48 37F (TRACKMOVE) Continue LIVE
'MvSrcUser_GetMovedUserBoxContent_Live'
(22 0x00000016): USERA (umz)
07:48:48 37F (TRACKMOVE) (.Move)
Items Sent (1494): USERA (umz)
07:48:48 37F (TRACKMOVE) (.Move)
AddressBook Components Sent (2): USERA (umz)
07:48:48 37F (TRACKMOVE) (.Move)
User Settings Sent (3): USERA (umz)
07:48:48 37F (TRACKMOVE) (.Move)
Remaining Inventory Count: USERA (umz)
07:48:48 37F (TRACKMOVE) END LIVE
'MvSrcUser_GetMovedUserBoxContent_Live'
(22 0x00000016): USERA (umz)
07:48:48 37F (TRACKMOVE) END PHASE
'MvSrcUser_GetMovedUserBoxContent_Live'
(0 0x00000000): USERA (umz)
07:48:49 37F Remote Request From: USERA
07:48:49 37F (TRACKMOVE) BEGIN PHASE
'MvSrcUser_DeleteMovedUser_Live': USERA (umz)
07:48:49 37F (TRACKMOVE) Sending LIVE
'MvSrcUser_PurgeUser': USERA (umz)
07:48:49 37F (TRACKMOVE) (.Move)
Sending LOCAL Purge Notification: USERA (umz)
07:48:49 37F (TRACKMOVE)
Sending ACTION_DELETE_USER: USERA (umz)
07:48:49 37F (TRACKMOVE) END PHASE
'MvSrcUser_DeleteMovedUser_Live'
(0 0x00000000): USERA (umz)

  9. Now that all the items have been received by PO2, the POA, the message items on PO1 are deleted and purged. Following are excerpts from PO1's POA log:

    07:49:09 397 Purge message record
07:49:09 397 Purge item record
07:49:09 397 Purge message record
07:49:09 397 (TRACKMOVE) Moved user deleted
'WpeDeleteUserExt' (0 0x00000000): USERA (umz)
07:49:09 397 (TRACKMOVE) Completed
'WpeDeleteUserExt' (0 0x00000000): USERA (umz)
07:49:09 397 (TRACKMOVE) Sending status
MOVE_USER_FINISHED: USERA (umz)
07:49:09 397 (TRACKMOVE) END PHASE
'MvSrcUser_DeleteMovedUser_Batch'
(0 0x00000000): USERA (umz)
07:49:09 397 Processed OK

The POA log files are very helpful when you're troubleshooting user moves. If a move becomes bogged down, study the POA logs; they are sure to indicate the problem that was encountered.

Key Technical Factors Related to a Move

Remember that a user move is a move of both a user's directory object and the user's messages. Moving the GroupWise user's message store tends to be much more problematic than moving the object in the GroupWise directory. An understanding of the move-user architecture can really help you out of a bind. The discussion in this next section still refers to USERA and other terms introduced previously.

The 12-Hour, 7-Day Clock

When the destination PO receives the inventory list, it puts the inventory list in the USER xxx.DB file for USERA.

Note

The xxx is replaced with USERA's file ID, or FID, as explained in Chapter 4, "Understanding the GroupWise Information Store."

The USER xxx.DB file should already exist because of the client options that were sent down by the destination domain at the beginning of the move. The POA will place the inventory list within the USER xxx.DB file. The pointer to the inventory list is also placed in the PO\OFMSG\NGWDFR.DB file (the deferred delivery database) on the destination post office. The inventory list in the deferred delivery database serves as a reminder to the destination PO to query the source PO for the items on the inventory list for USERA every 12 hours for 7 days. Items remaining on the inventory list indicate that the destination PO has not received all the items from the source PO. After all of a user's message items have moved across, and the purge notification is sent, the POA on the source PO deletes the pointer to the inventory list.

The reminder mechanism was designed to create a fail-safe message-store move operation.

Integrity of the Message Store

When a user moves from PO1 to PO2, the integrity of the message store on both post offices is important. The integrity of the message store on PO1 is critical. If a customer is implementing message-store maintenance routines on his GroupWise post offices, there is generally little concern about the message store. The move-user task list (in the upcoming section "Moving a GroupWise User") talks about which Mailbox/Library Maintenance/GWCheck routines to run on a user to be moved.

With live moves, the recommendation is still to move one user at a time. Multiple simultaneous moves can be successful, but if all client/server threads on the target POA are being used, the user move will be delayed up to 12 hours, unless the administrator intervenes with the User Move Status utility.

All GroupWise POAs attempt a live move first, before falling back to a message-store move. When you move a user, you cannot request a live move over a message-store move. The POA is hard-coded to attempt a live move if everything is in place. If for some reason you want to disable live move, do the following:

1. | Go to the destination's post office object in ConsoleOne.
2. | Go to the Properties of the post office object.
3. | Go to the GroupWise Post Office Settings property page.
4. | Check the Disable Live Move check box.
5. | Follow steps 14 on the source post office object as well.


Moving a GroupWise User

The following numbered list is an exhaustive task list for moving a user. If you are moving several users, most steps in the list can be done simultaneously for all users.

Tip

Do not proceed from one item to the next unless you have achieved success with the current task!

Here are some terms to keep in mind as you review the task list:

  • Destination domain: The domain that owns the post office the user is being moved to.

  • Destination PO: The post office that the user is being moved to.

  • Source PO: The post office that the user is currently a member of.

  • USERA: The user being moved.

Tip

The following is a tip from Richard Griffith, who has several years of experience with GroupWise.

"We have over 400 post offices in the company.

"Each small office has a post office due to bandwidth issues. I have noticed the default thread setting on the POA is too small, even though the post office may only have 12 users. The POA's default Max Thread Usage for Priming and Moves at 20% causes a problem. Twenty percent of 6 is 1.2. If the POA is doing anything with a TCP handler thread, the move will error. If I increase the threads to 12, user moves seem to happen more reliably. If I don't increase the thread, the log will display the following over and over: 18:19:09 24E (trACKMOVE) (Move.) Queue Live Deferred Retry Message (no thread available): rgriffith (a1c).

"The move may not take place for days and the user move status never clears, even though the move finishes sometime later."

So the recommendation here is based on Richard's observations. Increase the Max Thread Usage for Priming and Moves to 50% for post offices that have a small number (under 10) of TCP Handler Threads configured.

Following are the minimum recommended steps for moving a user:

1. | In ConsoleOne, connect to the destination domain. To do this, select Tools, GroupWise System Operations, Select Domain. Browse to the UNC path for the destination domain and select the WPDOMAIN.DB file. Tip Throughout the remainder of this list of steps, always stay connected to the destination domain.
2. | Check and clean USERA's message store with Mailbox/Library Maintenance routines. Note Avoid using the stand-alone GWCheck (GWCHECK.EXE). It is slower compared to the POA routines spawned from Mailbox/Library Maintenance. Highlight USERA and select Tools, GroupWise Utilities, Mailbox/Library Maintenance. Then select the Structural Rebuild option, make sure that only the User check box is checked under the Databases tab, and then click Run. Issue an Analyze/Fix Databases command on the contents of USERA's user database (don't bother with the message database). You can issue this Mailbox/Library Maintenance job immediately after issuing the structural rebuild. Confirm that both of these maintenance routines happened, and that there are no major problems with USERA's message store. Make sureif you are not set up as the GroupWise domain's administrator in ConsoleOnethat you CC yourself via the CC option on the Results tab.
3. | Make sure that USERA's object will synchronize to the source and destination POs. Temporarily change USERA's phone number. Log in as a test user on the destination PO and confirm that USERA's phone number changed, and that the user shows up as a member of the source PO. Log in as a test user on the source PO. Confirm that USERA's phone number changed, and that the user shows up as a member of the source PO. Change USERA's phone number back. Tip When you're moving a large number of users in a short period, it won't be practicable to take this step. Try to synchronize all the users, though. When moving multiple users, simply highlight the users to be moved by Shift-clicking or Ctrl-clicking, and then select Tools, GroupWise Utilities, Synchronize. Tip If you are going to move USERA to another eDirectory OU, go to step 4. If not, skip to step 5.
4. | Disassociate USERA's eDirectory object from the user's GroupWise object. Highlight USERA. Select Tools, GroupWise Utilities, GW/eDirectory Association, Disassociate GroupWise Attributes. Move USERA to her new eDirectory OU.
5. | View the details on USERA and make note of the FID. Highlight USERA and edit the properties. Select the GroupWise Account property page to take note of the file ID.
6. | Move USERA. Highlight USERA in the GroupWise view. Right-click the USERA object and select Move. Select the world icon in the GroupWise Move dialog box and browse to and select the destination post office. Follow the remaining prompts to allow the user to move.
7. | If you disassociated USERA's eDirectory object from USERA's GroupWise object, reassociate them. Highlight USERA in the eDirectory view, not the GroupWise view. Edit USERA, and go to the GroupWise Account property page. Click the world icon to the right of the Post Office field. Select the post office that USERA is now a member of. When you click OK as though you want to finish the operation on USERA, a message should come up that asks whether you want to associate USERA's eDirectory object with its GroupWise object. Click the Yes button, if everything is correct.
8. | Assess the success of your move. Do so using the User Move Status utility explained in the next section. Be sure to use the Clear Status feature when you have determined that the user did move successfully.

When you have confirmed that USERA has moved successfully, be sure to reassociate the user's GroupWise object with her eDirectory object. Do this by highlighting USERA in the GroupWise view and selecting Tools, GroupWise Utilities, GW/eDirectory Association, Associate Objects. Then associate USERA's GroupWise object with her eDirectory object.


Assessing the Success of a User Move

You moved a user and everything seems to be quiet on the POAs. You might now be asking, "Did everything get moved?"

The User Move Status utility is one of the best ways to assess the status of a user move. Here's how you assess whether a user move is successful. Follow these steps to use the User Move Status utility:

1.
Connect to the destination domain (the domain the user is now a member of) in ConsoleOne.

2.
Highlight the user who moved, and select Tools, GroupWise Utilities, User Move Status.

3.
When the User Move Status utility comes up, verify that the user's move status is Move Completed, as shown in Figure 13.2.

Figure 13.2. The User Move Status utility showing a successful user move

[View full size image]

The User Move Status utility shows several status reports for a standard successful move. We've listed most of them here, in chronological order:

Destination domain updated
Destination post office updated
Primary domain updated
Source domain updated
Source post office updated
Build item request
Fixing proxy lists
Retrieve mailbox items
Build item list
Mailbox inventory list received
Mailbox inventory transfer completed
Send item request
Completed retrieving items
Purge mailbox request received

The POAs for the source and destination post offices actually create these statuses at different stages during a user move. These statuses are sent as administrative messages. These administrative messages are sent up from the GroupWise POAs to the MTAs to commit to the GroupWise WPDOMAIN.DBs. You can read these statuses through ConsoleOne via the User Move Status utility.

If your user move happens quickly, it might be difficult to catch each of these statuses. The final status of Move Completed (assuming that the move was successful) will always remain until you actually remove the status via the Clear Status option from the User Move Status utility. We strongly recommend that you do click the Clear Status button. If you do not, and then later need to move the user again, you might have difficulty doing so.


Using the User Move Status Utility When Something Goes Wrong

There are a several kinds of move-user failures. Don't panicyou can generally dig your way out. This section looks at the most common kinds of failure, and covers how to solve those problems with the User Move Status utility. This discussion assumes that both the source and the destination post offices are running GroupWise 6.5 or 7 POAs.

The User Moved, but None or Only Some of the User's Messages Moved

A common scenario that you may run into is that a user gets moved, but either none or only some of the user's messages get moved. You could wait for 12 hours and let the POA try again. But why, when you've got the User Move Status utility? Consider the following scenario.

TKRATZER is being moved from MFGPO to PO2. He can log in to PO2, but none of his mail is in his mailbox at PO2. You can use the User Move Status utility to help kick off the move again:

1.
In ConsoleOne, highlight TKRATZER's user object in the GroupWise view.

2.
Select Tools, GroupWise Utilities, User Move Status.

3.
As long as the Last Move Status does not read "Move Completed," the Retry/Restart button should be available, as shown in Figure 13.3. Click the Retry/Restart button.

Figure 13.3. The User Move Status utility with the Retry/Restart button active

[View full size image]

This is a great feature, not just because you can kick-start the move, but also because you can look at the POAs or the POA logs and watch for what happens after you use Retry/Restart. There's another set of choices to make after starting the Retry/Restart option. Figure 13.4 shows you the choices you can make from this screen.

Figure 13.4. Choose from the Retry/Restart options

4.
Try taking the most conservative action, which is to choose the option to retry the last step of the mailbox move. It's important to note, though, that you really should observe the destination and source POAs to see what errors might appear after taking this action. Very often there's a good chance that this option won't advance the mailbox move process.

If the Retry the Last Step of the Mailbox Move option does not resolve the problem, and you have confirmed that your POAs aren't having a problem connecting to one another, generally the next best thing to do is choose the option Skip Retry on the Current Mailbox Item. This tells the POAs to skip the action they are currently trying to take, and move to the next action.

You then proceed to use the other options available to you in the Retry/Restart dialog box shown in Figure 13.4 if you determine the appropriate option to use. None of the options has the potential to be very harmful. You should feel comfortable using any of them.

The User Moved, but the User's Password Was Lost

If you have LDAP authentication enabled, this section does not apply to you.

This problem is similar to the preceding problem. A user's password is just another record in the User Settings section of the user database. The user settings are the last things to be moved in a mailbox move. It is possible that nothing was moved to the user's mailbox on the new post office. The best thing to do is reset the user's GroupWise password from ConsoleOne. The user can then access his mailbox and tell you the status of the move.

Other Features of the User Move Status Utility

There are some other options /buttons available to you in the User Move Status utility:

  • Info When you highlight a user in the status section and click the user's Info button, you will see all the info on that user. This can be particularly helpful when there is a long error message associated with the user move. You'll have difficulty seeing the error unless you use the Info button. Scroll down until you see the Move Error or Move Status field.

  • Pending Items When you highlight a user in the status section and click the Pending Items button, you can request a listing of the items that the destination post office has yet to receive. What is particularly helpful about this feature is that it can act as a tool to identify the item that is in a stuck state. Then you might use the Skip Retry on Current Mailbox Item option from the Retry/Restart dialog box. Figure 13.5 shows the Pending Items dialog, showing items pending from a user move that is in progress.

    Figure 13.5. Pending items for a move in progress

    [View full size image]

  • Force Complete If users are satisfied that they have everything they want, but the POAs still are being held up by something, you can use Force Complete. It tells the POAs to stop trying to move anything else, and to purge the user's mailbox from the source post office. You should always determine whether a user move was successful. If the status in ConsoleOne does not indicate Move Completed but your user is satisfied with the move, use the Force Complete option. If you do not, it's possible that the source post office won't thoroughly purge messages that should be purged from the source post office.

  • Clear Status This option just clears the current status you are highlighting. If the status is anything other than Move Completed, when the POAs send up their next move status message, that new status message will appear. You should use the Clear Status button after a user's move is successful (Move Completed), or after you've forced it to complete with the Force Complete button.

  • Clear All Complete This is kind of like a bulk Clear Status option for clearing the Move Completed status on user objects that have successfully moved.

The User Move Status utility also tracks resource moves.


Tips for Moving Many Users

Many GroupWise customers are consolidating GroupWise post offices. There are a few actions you should take to ensure that the move-user process goes successfully:

  • Make sure that QuickFinder Indexing is not scheduled to run while the user moves are happening. If needed, disable QuickFinder Indexing. Be sure to reenable it when the job is done.

  • Make sure that every POA has at least six TCP handler threads and six message handler threads configured, at minimum! If you have a small post office, you may wonder why you are told to break with the protocol of having half the number of message handler threads as TCP handler threads. The reason for this recommendation is that if the TCP handler threads or message handler threads become too busy, the whole move may stop for 12 hours. It's better to increase threads than to allow that to happen. When moving a big load of users, you might consider doubling both the TCP handler threads and the message handler threads on both POAs during the period you are moving users.

  • On the POA's Agent Settings screen, there's a Max Thread Usage or Priming and Moves option. The default is set to 20%, which is generally sufficient. But during the time that you are moving users, you should consider changing this valueperhaps to around 80%. Move this setting back down after the moves have completed.

  • Because you will likely be sending Mailbox/Library Maintenance/GWCheck jobs to the source POA, you should consider increasing the maintenance handler threads. If you do so, the Mailbox/Library Maintenance/GWCheck jobs will happen faster, unless your server's CPU is too slow to handle so many GWCheck threads at once. You can do this by going to the Maintenance property page of the destination POA. The default is four maintenance handler threads; the maximum is eight. Increase this number when performing maintenance on the users to be moved, and then lower the setting as needed after the user moves.

Follow these tips, and your user moves should go faster. The real keys to successful user moves include following the directions in the section "Moving a GroupWise User" and ensuring that the destination and source post offices have been maintained with schedule maintenance events all along.


Summary

This chapter discussed moving users safely and troubleshooting user moves that have gone awry. To ensure safe user moves, do the following:

  • Clean the user's message store before initiating the move. It is also assumed that the source and destination post offices have regular Mailbox/Library Maintenance scheduled event routines enabled.

  • Don't move more than 10 users at a time (unless you've carefully benchmarked the move process on your system).

  • Be connected to the destination domain when initiating the move.

When troubleshooting moves that have not gone well, remember these tips:

  • Don't panic; read the sections of this chapter that talk about the move-user architecture.

  • Determine the extent of the failure of the move (messages missing, directory entries incorrect, and so on) before taking any action.

  • Use the user move status and the POA logs to determine the problem.


Chapter 14. Working with GroupWise Agents on the Linux Platform

Running GroupWise Agents on the Linux platform isn't particularly difficult; however, Linux conventions might be difficult for the common GroupWise administrator to grasp. This chapter seeks to look more closely at the GroupWise Agents, and discusses how they are started, are configured, and function on the Linux platform.


Linux Conventions

There are many Linux conventions that GroupWise tries to adhere to. These conventions govern where GroupWise Agent code is installed, how these agents are loaded, and where the GroupWise Agents keep their logs. To a GroupWise administrator, it may seem that things are a bit scattered; however, this is done in order to comply with Linux convention. As you implement GroupWise on Linux, you will learn the conventions of Linux simultaneously, which will help you work with other Linux software.


GroupWise Agent Code Installation, Configuration Files, and Agent Startup

The GroupWise Linux agents are installed to the following path on a Linux server:

/opt/novell/groupwise/agents/bin

The startup files for the GroupWise MTA, POA, WebAccess Agent, and GWIA are all kept in the following path:

opt/novell/groupwise/agents/share

All GroupWise Agents share similar library code. This code is kept in the following directory:

/opt/novell/groupwise/agents/lib

To see the version of GroupWise Agent code you are running, issue the following command in a shell prompt at the Linux server:

rpm qa | grep groupwise

Figure 14.1 shows the results of this command on a SUSE SLES9 server.

Figure 14.1. Determining installed GroupWise software

[View full size image]

The challenge with using library code is that if you go to install a newer version of GroupWise code, you often will get an error, which means that the new code cannot install because of the older code that exists. In our experience the error is typically an "error 7," as shown in Figure 14.2.

Figure 14.2. An error 7 from a GroupWise library mismatch

Resolving this problem can be a little tricky. You need to uninstall all the GroupWise code that is conflicting, and then reinstall all the GroupWise code at the same release level. Kind of a painful exercise! What makes this exercise even more interesting is that the uninstall method removes configuration files too. So if you have much invested in a startup file, you will lose your work if you don't back it up prior to uninstalling the code. For most agents there isn't much invested in the startup file; however, the gwia.cfg file, which is the configuration file for the GWIA, gets deleted if you uninstall the GWIA code. Let's quickly outline the steps you could take to uninstall GroupWise Agent code without losing your current configuration.

To make this task easier, let's talk through this procedure as if it were a real-world scenario.

The GroupWise 7 Support Pack #2 came out recently. The GroupWise administrator sets out to install the new GroupWise Agent code and the GroupWise GWIA on a Linux server. When attempting to install the GroupWise Agent code, the administrator encounters an error 7, as shown in Figure 14.2. These are the steps the administrator could take to resolve the problem:

1.
Back up the contents of the following directory:

/opt/novell/groupwise/agents/share

You can do so by making a directory and then copying the files to this directory (see Figure 14.3).

Figure 14.3. GroupWise software uninstallation steps

[View full size image]

2.
In a terminal session enter the following command to see the name of GroupWise Agent code that is installed:

rpm qa | grep groupwise

The output of the command is shown in Figure 14.3.

3.
In our sample scenario, the GroupWise Agent and GWIA software are installed. So the next step is to uninstall the GroupWise Agent and GWIA software with the following commands:

rpm e novell-groupwise-gwia
rpm e novell-groupwise-agents
rpm e novell-groupwise-gwha

Figure 14.3 shows the use of these commands.

4.
Install the GroupWise Linux agent software. Be sure to install the Linux agent software, and configure it also.

5.
Install the GroupWise GWIA software. Be sure to install the software and configure it also.

6.
Restore the files that you backed up from the ../ share directory.

Now you have successfully uninstalled and reinstalled GroupWise Agents without the loss of configuration data.


The /etc/init.d/grpwise Script

The /etc/init.d/grpwise script is a BASH Shell script. The grpwise script is what you are most likely to use to load and unload GroupWise Agents on a Linux server. The grpwise script should be considered code, and should generally not be modified. The grpwise script can be used with various commands. For example:

To start all GroupWise Agents:

/etc/init.d/grpwise start

To stop all GroupWise Agents:

/etc/init.d/grpwise stop

To determine the status of all GroupWise Agents:

/etc/init.d/grpwise status

Imagine, though, that on a particular Linux server you have the MTA and the GWIA running. You need to take down the GWIA, but not the MTA. The GWIA is called GWIA and the domain that the GWIA is associated with is called MARKET. Here isthe method you would use to unload the GWIA:

/etc/init.d/grpwise stop GWIA.MARKET

And here is the method you would use to unload the MTA for the MARKET domain:

/etc/init.d/grpwise stop MARKET

Figure 14.4 demonstrates using the grpwise script.

Figure 14.4. Using the grpwise script

[View full size image]

The fact that the grpwise script is in the /etc/init.d directory ensures that when the server boots, the GroupWise Agents will start up on server startup.


The /etc/opt/novell/groupwise/gwha.conf File

The grpwise script consumes the contents of the /etc/opt/novell/groupwise/gwha.conf file. The gwha.conf file is used by the grpwise script to start a particular GroupWise Agent, and to tell this agent which startup file to use for the particular instance of the GroupWise Agent. Here is a sample gwha.conf file:

[gwha]
ssl       = no
key       =
cert      =
password  =

[MARKET]
server    = /opt/novell/groupwise/agents/bin/gwmta
command   = /etc/init.d/grpwise
startup   = market.mta
delay     = 2
wait      = 10

[GWIA.MARKET]
server  =  /opt/novell/groupwise/agents/bin/gwia
command =  /etc/init.d/grpwise
startup =  gwia.cfg
delay   =  2
wait    =  10

The gwha.conf file gets created when you run the "Configure" portion of the install of the GroupWise Agents or GWIA software. However, there is a very important step you need to keep in mind. The gwha.conf file is not actually fully functional until you have successfully started the GroupWise Agent one time. The next section, "Initializing GroupWise Agents," talks about how you do this, so be sure to read that section. The gwha.conf file is part of the GroupWise high-availability system that functions only on the Linux platform, and integrates with Novell GroupWise Monitor. At the time this book was being written, the high-availability pieces were still being worked on, so we cannot tell you just how to configure this feature. It sounds as though it will be a great feature, so see the online GroupWise documentation at http://www.novell.com/documentation.


Initializing GroupWise Agents

There are two methods for starting a GroupWise Agent on Linux, and you must know both methods. In fact, when you first install a GroupWise Agent, you must first start it in a somewhat manual fashion. We call this "initializing" the agent. Then, every time after the initialization of the agent, you can bring up the GroupWise Agent in the simpler manner explained earlier in this chapter. Namely, the simpler manner of loading a GroupWise Agent is to type a command similar to this: /etc/init.d/grpwise start MARKET.

The purpose of "initializing" a GroupWise Agent is hard to convey without doing so in the form of a scenario. Here is our scenario:

In our system there is a domain called MARKET that resides on a Linux server. We have just installed a GWIA onto the Linux server. Now we would cause the GWIA to come up by typing the command grpwise start, or grpwise start GWIA.MARKET. However, when we issue the command grpwise start, the script says that it's initializing @gwia. Kind of confusing!

Here's what you must do to correct this problem:

1. | Start the GWIA manually (we'll explain how to do that in a moment).
2. | Stop the GWIA.

After this, the syntax ../grpwise start will no longer give the message about @gwia.

To load the GroupWise GWIA manually, do this:

1.
Stop the GWIA if it is currently running:

killall gwia

Or use this:

/etc/init.d/grpwise stop

2.
Change to the code directory for the GroupWise GWIA:

cd /opt/novell/groupwise/agents/bin

3.
Fire up the GWIA and point it to the gwia.cfg:

./gwia show @../share/gwia.cfg

4.
When the GWIA successfully loads, it should modify the gwha.conf file that we mentioned before. This change means that the GWIA can now be successfully stopped and started using the simpler format of /etc/init.d/grpwise start GWIA.MARKET.


Locating GroupWise Agent Log Files

Linux conventions dictate that log files should be located in a more generic "logs" directory. So GroupWise Agent log files are kept in the following path, as long as you don't specify a different path:

/var/log/novell/groupwise

Off of this directory structure, there is a directory specific to each GroupWise Agent running on the Linux server. On our sample Linux server there is a domain called MARKET and a GWIA off of the domain. Figure 14.5 shows the contents of the /var/log/novell/groupwise directory on our sample Linux server.

Figure 14.5. The contents of the /var/log/novell/groupwise directory

[View full size image]


Summary

This chapter explained the essential steps to getting GroupWise Agents on the Linux platform to load correctly. This chapter also explained the inner workings of how GroupWise Agents are configured on the Linux platform.


Chapter 15. Administering Multiple GroupWise Systems

It is not uncommon, in this age of mergers, acquisitions, and outsourcing, for an administrator to be confronted with the task of administering more than one GroupWise system. This chapter covers the tasks that are common to multiple-system administration: merging systems, releasing systems, and synchronizing address books between systems.


Multiple-System Concepts

Before we discuss the tasks common to multiple-system administration, there are several concepts you need to understand. The following sections walk through those concepts.

The Primary Domain Defines the System

If you are working with more than one GroupWise system, you are also working with more than one primary domain. The primary domain database, WPDOMAIN.DB, contains complete information about all objects contained in its GroupWise system.

To administer multiple systems, you need to know which primary domain owns which objects. You also need to know which system you are connecting to when you make changes.

External Domains Are Placeholders

A primary domain can contain a special kind of recordan external domain record. This is essentially a placeholder that allows the primary domain to be aware of the existence of another GroupWise system. Note, however, that this placeholder does not give the primary domain any control over objects that exist in the other system.

External domains allow you to manage the connectivity between two or more GroupWise systems as if they were a single systemalmost. You will use external domain records as you merge systems into a single system, or release domains into their own systems. You will also use external domain records to set up address-book synchronization between two systems that are external to each other.

Releasing Domains

When a GroupWise secondary domain needs to become its own system (as part of an outsourcing contract, perhaps), the administrator must tell the primary domain to release the secondary domain that must be let go.

The secondary domain then becomes the primary domain in its own, single-domain system.

Merging Systems

When two GroupWise systems need to be combined, the primary domain for one system will release all of its secondary domains. This, in effect, creates several GroupWise systems, each with its own primary domain. The primary domain for the destination system must adopt each of these domains in turn. Thus, when merging two systems, you must first go through the process of releasing all the secondary domains on one of the systems.

When the merges are complete, all domains will belong to a single system, and there will be only one primary domain. Of course, partial merges are not uncommonone department or division might be sold to another company. In this case, that division's domain would be released from the original system and merged with a new one.

Synchronizing Systems

When two GroupWise systems need to remain separate, but also need to share their address books, the administrator can enable external system synchronization. This can be a great boon to productivity.

The downside to external system synchronization is that it can potentially bloat the GroupWise directory, making rebuild times on WPDOMAIN.DB and WPHOST.DB files longer. This is typically the case when two very large organizations (5,000 or more users) decide to synchronize their address books. Some customers choose to use an LDAP solution, to create address-book solutions that do not bloat the GroupWise directory.


Releasing a Secondary Domain to Create a New GroupWise System

Now that the concepts are covered, this section provides a walkthrough of the first of the multiple-system scenarios discussed in this chapter.

The WorldWide Widgets Corporation has decided to outsource its manufacturing division. The manufacturing division is its own separate company called ACME. It will have its own eDirectory tree, named ACME. The following is a discussion of how ACME and WorldWide Widgets pull this off.

ACME's PreDomain Release Preparation

First of all, ACME is going to be getting new file servers as part of the outsourcing. Take the following steps before releasing the secondary domain to become a new system:

1.
Install a new GroupWise Software Distribution Directory to ACME's NetWare server.

2.
Install the latest patches to the GroupWise Software Distribution Directory.

3.
Install the GroupWise agents so that they are ready to run on the ACME server.

4.
Create an eDirectory OU named APPS, to house the GroupWise system for manufacturing.

5.
Create an eDirectory OU named STAFF, to house the manufacturing staff.

Figure 15.1 shows the ACME tree.

Figure 15.1. The ACME location shown in ConsoleOne

[View full size image]

Figure 15.2 shows how the manufacturing division currently looks in the WorldWide Widgets system.

Figure 15.2. The manufacturing division at WorldWide Widgets

[View full size image]

6.
Move the MFG domain and the MFGPO post office to the ACME server so that they physically reside on the ACME server.

This operation is covered in Chapter 21, "Moving Domains and Post Offices."

7.
Check that the MFG domain has no pending operations. To do this, choose Tools, GroupWise System Operations, Pending Operations.

The preparation steps are finished. Now the domain can be released.

WorldWide Widgets: The Release

The WorldWide Widgets administrator is now all set to release the MFG domain. Follow these steps to release a secondary domain:

1.
Connect to the primary domain named CORP.

2.
Select the MFG domain.

3.
Choose Tools, GroupWise Utilities, System Maintenance.

4.
In the GroupWise System Maintenance screen, select the Release Secondary option, as shown in Figure 15.3, and click Run.

Figure 15.3. The Release Secondary option appears in the GroupWise System Maintenance dialog box

5.
When the Release Domain Wizard comes up, click the Next button. You'll advance to the screen where you specify a path to the MFG domain. Click the Next button again.

6.
Now you see a window that allows you to name the ACME GroupWise system. In this example the name of the new GroupWise system is ACME_Mail.

Tip

The name of the new system must not be the same as that of the old WorldWide Widgets GroupWise system. If you ever need to determine the system name of a GroupWise system, highlight any object in the left pane of the GroupWise view, and at the bottom of the status tray in ConsoleOne, you will see the system name. In Figure 15.2, you can see that the name of the existing system is World_Wide_Widgets_Mail.

7.
The Release Domain Wizard prompts you to update eDirectory objects.

You will want to do this. This option takes the MFG and MFGPO1 objects out of the WorldWide Widgets eDirectory tree.

8.
Follow the Release Domain Wizard's prompts to unload the message transfer agent (MTA) on the primary domain, as well as on the MFG domain that is being released.

9.
The final dialog box says that you are ready to release the domain. Click the Release button.

The domain is released and becomes an external GroupWise domain to the World_Wide_Widgets_Mail GroupWise system. The MFG domain becomes its own primary domain over the ACME_Mail system. The domains in the World_Wide_Widgets_Mail GroupWise all show up as external to the ACME_Mail system. Figure 15.4 shows how the GroupWise view looks when connected to the CORP domain.

Figure 15.4. The newly revised GroupWise system

[View full size image]

Tip

When writing this section and following the steps outlined in this section, we received errors when we tried to release a secondary domain. The errors seem to have been related to removing the Update eDirectory Objects selection that we made. The MFG domain was released, despite the error, but we didn't know that until we actually connected to the domain that we released. When we did connect, we saw that the old primary domain was a white earth icon, rather than a blue earth icon, which told me that the domain had in fact been released. Also when we edited the MFG domain, we could see that the domain type was primary.

The domain is now released, but that's not the end of the story. The MFG domain and the MFGPO1 post office still need to be grafted into the ACME tree. And three usersECORNISH, IMESSENGER, and WROBERTSstill need to be created in the ACME tree. Here's the process to follow:

1.
Log in to the ACME tree.

2.
Connect to the MFG domain, which is now a primary domain. To do this, select Tools, GroupWise System Operations, Select Domain.

3.
Go into the eDirectory browser portion of ConsoleOne. Highlight the APPS organizational unit.

4.
Choose Tools, GroupWise Utilities, GW/eDirectory Association, Graft GroupWise Objects. The Graft GroupWise Objects Wizard appears.

5.
Select the domains, post offices, and gateways option, and proceed through the wizard. Do not attempt to graft users until you read the next step. In the ACME_INC tree,the MFG domain (and the MFGPO post office) will be grafted into the APPS.ACME eDirectory context, as shown in Figure 15.5.

Figure 15.5. Grafting the MFG domain

[View full size image]

Now the MFG domain and the MFGPO post office are in the eDirectory tree. You can now try to graft the users into the new ACME_INC tree. This process isn't quite as straightforward as grafting the domain and post office. The great thing about this procedure is that you do not have to manually re-create your users into eDirectory.

Following are sample procedures for grafting the users from the MFG domain into a new eDirectory tree:

1.
From the eDirectory browser view, highlight the STAFF context and then choose Tools, GroupWise Utilities, GW/eDirectory Association, Graft GroupWise Objects.

2.
Select the option to graft users, resources, distribution lists, and libraries.

Follow the prompts of this wizard, being sure to specify the right eDirectory contexts, as well as the eDirectory contexts in which the users who moved with MFG have been created. See Figure 15.6.

Figure 15.6. Grafting users and other objects is possible using the Select Objects dialog box

[View full size image]

3.
Proceed to the Unmatched Users screen, shown in Figure 15.7. Choose the option to create the users as GroupWise external entities.

Figure 15.7. Unmatched users will become GroupWise external entities

[View full size image]

4.
Proceed through the rest of the grafting wizard.

Now the users are GroupWise external entities; they are not full eDirectory users, as shown in Figure 15.8. The next few steps describe how to convert these GroupWise external entities into full eDirectory users.

Figure 15.8. GroupWise external entity users are users without an eDirectory account

[View full size image]

5.
Highlight all the GroupWise external entities in the eDirectory browser view. Then select Tools, GroupWise Utilities, GW/eDirectory Association, Convert External Entity to User.

6.
In the Convert External Entity to User dialog that appears, select Yes All. The users become full eDirectory user objects, as shown in Figure 15.9.

Figure 15.9. Full eDirectory user objects

[View full size image]

You have created your user objects in eDirectory. You should now give the users rights throughout your eDirectory as needed.

Final Steps and Cleanup

The new GroupWise system needs to have a Software Distribution Directory definition pointing to the newly installed GroupWise Software Distribution Directory. You define a Software Distribution Directory under Tools, GroupWise System Operations, Software Directory Management, as outlined in Chapter 6, "Using GroupWise System Operations."

The MFGPO1 post office needs to have its "software directory" pointing to the new ACME Software Distribution Directory.

The users in the ACME tree should be given browse, read, and compare rights to the MFG post office, as well as the POA below that post office object. This will allow users' GroupWise clients to dynamically discover their new POA IP address.

In this example, WorldWide Widgets and ACME do not need to reference each other anymore. Both sides will delete any reference to one another. This means that the WorldWide Widgets administrator will delete the external domain for manufacturing, and the administrator of the ACME_Mail system will delete all external domains left over from the WorldWide Widgets system. First, though, in each system the administrators must go to Tools, GroupWise System Operations, External System Synchronization and delete the reference they have to one another. Then they should be able to delete the external domain reference to one another.

The manufacturing division's eDirectory user objects should also be deleted from the WorldWide Widgets eDirectory tree.


Synchronizing External Systems

Continuing the World Wide Widgets and ACME Manufacturing scenario, imagine that the people at WorldWide Widgets acted a little hastily. They deleted all user objects and external references to manufacturing, but now they discover that their users need to exchange address books.

For the balance of this chapter, the GroupWise system for WorldWide Widgets is called System 1; ACME's system is called System 2.

Creating System Definitions for Synchronizing

First, from System 1, you need to create a definition for System 2.

Following are the steps for creating a reference to an external system:

1.
Highlight the GroupWise system object. Then select File, New, External Domain.

2.
Fill out the appropriate System 2 information in the Create External GroupWise Domain dialog box (see Figure 15.10). To do external system synchronization, you must define the primary domain for the other system as the new external domain.

Figure 15.10. Creating a new external domain in another GroupWise system

At this point, the MFG domain again exists in the WorldWide Widgets system, but only as an external domain. The post office below the MFG domain and the users on that post office are not currently represented.

Tip

External domains appear as a white earth icon, rather than a blue earth icon.

Tip

When defining an external GroupWise system for synchronization purposes, you must define the primary domain for that system. Defining a secondary domain in another system, rather than the primary domain, is fine, but a secondary domain does not support external system synchronization.

To create a definition for System 1 from System 2, you need to repeat the procedure earlier in this section, but from System 2's perspective. Follow these steps to create a reference to an external system:

1. | Connect to System 2 and highlight the GroupWise system object in the GroupWise view.
2. | Click the right mouse button, select New, and then select External Domain.
3. | Fill out the information appropriate for System 1.

At this point, the CORP domain exists in the ACME_Mail system, but only as an external domain.

Creating MTA Connectivity

To create MTA connectivity between System 1 and System 2, you need to define how System 1's MTAs deliver messages to System 2's MTAs, and vice versa. Follow these steps to create MTA-level connectivity between two GroupWise systems:

1.
While connected to System 1, choose Tools, GroupWise Utilities, Link Configuration.

2.
Edit the link from the primary domain to System 2's external domain.

Fill in the correct information so that the MTA on System 1 can contact the MTA on System 2, as shown in Figure 15.11.

Figure 15.11. Link configuration for MTA connectivity to an external GroupWise domain

[View full size image]

3.
While connected to System 2, choose Tools, GroupWise Utilities, Link Configuration.

4.
Edit the link from the primary domain to System 1's external domain.

Fill in the correct information so that the MTA on System 2 can contact the MTA on System 1.

Now the MTAs of both systems know how to transfer messages between systems.

Testing System Connectivity

Before enabling external system synchronization, you need to test the connection. Otherwise, you might end up with thousands of address-sync messages queued up in DOMAIN\MSLOCAL\MSHOLD directories.

Following are the steps to test system connectivity between two external GroupWise systems:

1.
Send an email from a user on System 2 to a user on System 1.

To do this, compose a message in this manner: On the To line, type the name of the external domain followed by the post office and username, all separated by dots.

For example, you want to send to the user TKRATZER on the post office CORPPO off of the CORP domain in System 1. The To line of the message should read CORP:corppo.tkratzer. Figure 15.12 shows this syntax.

Figure 15.12. Sending email to an external system via the connection to an external domain

[View full size image]

Tip

Suppose that the CORP primary domain does not have a post office under it. There is a post office under the Sales domain though. You can still send from System 2 to System 1. You can utilize the connection to CORP to route a message to the Sales domain. Here's how the To line would appear: CORP:SALES.SALESPO.TKRATZER.

2.
Confirm that the email went through.

Check the properties of the original sent item. Does it say that it was delivered? If so, the connection in both directions is okay. You know this because the original message was delivered (System 2 to System 1), and the delivered status message came back (System 1 to System 2).

Now that you have confirmed that both sides can send one another messages, you are ready to enable external system synchronization.

Configuring External System Synchronization

Now you know that communication works between the two systems, so you are ready to synchronize their address books. This operation requires that you make changes on both systems.

Following are the steps for configuring external system synchronization:

1.
Connect to System 1's primary domain.

2.
Choose Tools, GroupWise System Operations, External System Synchronization.

3.
Click the Add button and fill in the GroupWise system name for the external system.

In the sample scenario, it is ACME_Mail. Pay attention to the spelling and casethis field is case-sensitive. The name acme_mail would not be correct.

4.
In the External Domain field, browse to the external domain's primary domain that represents System 2's connectivity point.

5.
Select the options to send and receive the domains, post offices, and users from the external domain.

Figure 15.13 shows a configured external domain link from System 1 to System 2.

Figure 15.13. Setting up external system synchronization for System 1

6.
Click OK.

7.
Connect to the primary domain on System 2.

8.
Choose Tools, GroupWise System Operations, External System Synchronization.

9.
Click the Add button and fill in the GroupWise system name for the external system.

In the sample scenario, it is World_Wide_Widgets_Mail.

10.
In the External Domain field, browse to the external domain that represents System 1's connectivity point.

11.
Select the options to send and receive from the external domain: the domain, post offices, and users.

All systems are go, but you still have not kicked off the initial synchronization between both GroupWise systems. These steps are covered in the next section.

Synchronizing Systems

Now that both sides are prepared to send changes to each other, you must kick off the synchronization by having each side request all the objects it needs from the other side.

Following are the steps to initiate external system synchronization:

1. | While connected to the System 1's primary domain, choose Tools, GroupWise System Operations, External System Synchronization.
2. | Highlight System 2's external system and click the Request button. Be aware that this step does generate a lot of trafficat least one mail message per user on System 2.
3. | While connected to System 2's primary domain, choose Tools, GroupWise System Operations, External System Synchronization.
4. | Highlight System 1's external system and click the Request button. Again, be ready for lots of traffic.

If all goes well, both sides should synchronize, and the post offices and users from the external system will be visible.

Tip

We have worked with external system synchronization problems several times. Based on the experience we have had, it's quite possible that you will need to request the objects a few times. If it appears as though the request operation just does not get all the objects from the other GroupWise system, you can synchronize the users manually from System 1. This information will automatically replicate to System 2 as well. This might help to get all objects synchronized between both systems the first time.


Merging Two External GroupWise Systems

This walkthrough takes you through the process of merging two GroupWise systems. The primary domain in System 2 will become subordinate to the primary domain in System 1, which means it will eventually be converted to a secondary domain.

Note

Only primary domains can be merged with an existing system, and they can be merged only if they do not own any secondary domains. If you need to merge a multidomain system with yours, you must first have that system release all of its domains. Refer to the section "Releasing a Secondary Domain to Create a New GroupWise System," earlier in this chapter.

The Merge Scenario

The WorldWide Widgets Corporation wants to acquire the ACME Corporation. (Forget, for just a moment, that you released the ACME system in an earlier walkthrough. Or perhaps you could assume that this is a real-life example of a confused corporate reorganization.)

They both have GroupWise systems. It is natural for them to merge their two systems. This will cause the MFG domain to be a GroupWise secondary domain to the CORP primary domain. WorldWide Widgets and ACME will still keep separate trees, however. Remember that System 1 is WorldWide Widgets' system, and System 2 is ACME's system.

Creating System Definitions for Merged Systems

From System 1, follow the steps to create a definition for System 2. From System 2, follow the steps to create a definition for System 1. All the steps are in previous sections of this chapter. Follow all the steps in the sections "Creating System Definitions for Synchronizing," "Creating MTA Connectivity," and "Testing System Connectivity."

On System 2 (the system that will be merged), follow all the steps necessary to release its secondary domains. The steps for doing this are described in the section "Releasing a Secondary Domain to Create a New GroupWise System."

Tip

The reason for releasing domains is that you cannot merge another GroupWise system when it contains multiple domains. You must pare it down to a single primary domain to merge it into a different GroupWise system.

Now, connect to System 1's primary domain (the domain that will assimilate System 2). Log in to the eDirectory tree that houses the primary domain for System 2. In this scenario it's the ACME_INC TRee, and the domain is the MFG domain.

Highlight the external domain that represents the primary domain that you are assimilating to become a new secondary domain. Select Tools, GroupWise Utilities, System Maintenance. Choose the option Merge External Domain and then click the Run button. Follow the prompts of the Merge External Domain Wizard. When you get the prompt Update eDirectory Objects, choose No, at least in this scenario in which the MFG domain will still be contained in the ACME_INC tree.

When prompted to do so, bring down the MTA for both of the primary domains. Proceed through the wizard, and merge the two systems.

Tip

If you get the Merge Domain Error, there is an MTA or a gateway still up that is accessing the WPDOMAIN.DB, or ConsoleOne is tripping over its own shoelaces (this is often the case in scenarios such as this). The solution is simple. Make sure that you are connected to System 1's primary domain, and then exit ConsoleOne. Load ConsoleOne, and then attempt the merge again. If the problem persists, someone else is accessing the WPDOMAIN.DB for the primary domain for either System 1 or System 2. You can use Monitor on NetWare and check for File, Open Lock activity, and then browse to the WPDOMAIN.DB file to determine who is accessing the database.

Synchronizing Objects

Merging two systems is rather easy. However, the merge does not broadcast the new objects brought in from System 2 to the rest of System 1. Also, the domains and post offices originally associated with System 2 don't have a clue about the objects in their new system.

To get all domains and post offices acquainted with the new, larger system, you must perform a top-down rebuild. This can be a big task. A top-down rebuild requires that all GroupWise domains and post offices be rebuilt. Here are some important pointers for top-down rebuilds:

  • Before rebuilding a secondary domain, synchronize it with the primary domain. See the beginning of this walkthrough for instructions on how to do this.

  • Rebuilding a GroupWise domain or GroupWise post office database requires exclusive access to that database.

  • For more information about rebuilding domain and post office databases, refer to Chapter 22, "Troubleshooting the GroupWise Directory."

After the top-down rebuild, all GroupWise domains and post offices should be aware of the new domains and post offices.


Defining IDOMAINs for an External Domain

This is kind of an obscure feature, but you might find it handy. First off, Chapter 16, "Internet Addressing," talks in more depth about IDOMAINs. Just in case you wanted to know, there is a way to define the Internet domain for an external GroupWise system. Here's an example of how this feature might be applied. Users at WWWIDGETS.COM are accustomed to sending messages to users at ACMEWIDGETS.COM. Now, though, these two systems are connected to one another and they do external system synchronization. There is no longer a reason for users at ACMEWIDGETS.COM to send to users via the syntax USERID@WWWIDGETS.COM.

There's no reason for users at WWWIDGETS.COM to send to USERID@ACMEWIDGETS.COM.

The users should just select one another from the address book. But alas, old habits are hard to break. The impact is that messages are not being kept in their native GroupWise format, and they are being sent out the GWIA. We will explain the solution to this problem from the perspective of the system with the WWWIDGETS.COM IDOMAINin this scenario, this is the system that has the CORP domain as the primary domain. Here's the solution:

1.
Connect to System 1's primary (called CORP).

2.
Highlight the external GroupWise domain. In this scenario the name of the domain is MFG.

3.
Edit the properties of the MFG domain.

4.
Select the Internet Addressing property page under the GroupWise tab.

5.
Place a check mark next to the Internet Domain Name field.

6.
Fill in the Internet Domain Name field with the Internet domain name of the external domain. See Figure 15.14.

Figure 15.14. Defining an IDOMAIN for an external domain

[View full size image]

7.
Repeat these steps for all domains in the external system.

Now, since you have defined the IDOMAIN for your external GroupWise system, messages sent to the external domain's Internet domain will not pass through the GWIA. This will allow the messages to contain more formatting and features, such as status tracking.


Summary

The GroupWise directory is fairly flexible in allowing you to work with multiple GroupWise systems. The decision to merge systems rather than simply synchronizing them is one for you to make. There are advantages and disadvantages to each approach.

Chapter 16 talks about Internet addressing, which enables another means for communicating effortlessly with other email systems on the Internet.

There are a few advantages to merging systems: They include synchronization between domains automatically and require no additional configuration. They include a single primary domain database, which allows for central administration. Distributed administration is possible.

Merging systems does, however, have its disadvantages. These include adding the necessity for some degree of central administration. This might not be appropriate for some organizations. Additionally, the larger the system is, the more crowded the address book becomes.


Chapter 16. Internet Addressing

As mentioned in previous chapters, GroupWise features an option for Internet addressing. By default, when you install GroupWise, Internet addressing is not enabled, so you should take steps to enable it as soon as possible. As GroupWise evolves, certain features rely on your having Internet addressing enabled. This chapter examines the Internet addressing standard and explores the changes that take place when Internet addressing is enabled on a GroupWise 6.x or 7 system.


Overview of GroupWise Internet Addressing

To begin with, it is important to provide a high-level overview of what GroupWise Internet addressing is and give the background as to why Internet addressing was added to GroupWise. More detail will follow on the basics of Internet addresses and how GroupWise addressed messages using the old-style addressing scheme before GroupWise supported Internet addressing.

GroupWise was designed and engineered before the Internet was widely in use for sending SMTP messages via email. As a result, GroupWise, like many other solutions from that same time period, used a proprietary addressing scheme made up of the following elements: domain, post office, and userID. Because of this, if you were to create a new GroupWise system and then install the GroupWise Internet Agent (GWIA) to send SMTP messages via the Internet, your users would not be able to simply type an address in the format of user@internetdomain.com and expect the GroupWise system to know what to do with this address. Before GroupWise supported native Internet-style addresses, the administrator got around this issue by setting up a series of system addressing rules that allowed users to send mail in the format of user@internetdomain.com.

Novell, knowing that GroupWise must be able to natively understand Internet-style addresses, came up with a solution that was first introduced in GroupWise 5.5. This is where the term Internet addressing was introduced to GroupWise.

When an administrator enables Internet addressing, all GroupWise agentsincluding the GroupWise clientbecome aware of this fact, and are able to resolve Internet-style addresses natively. This gives the administrator a lot of flexibility regarding the way in which GroupWise can address and resolve Internet-style addresses.

The following sections explore the details of Internet addressing.


Defining an Internet Address

Internet addressing is the standard addressing format used to route and resolve Internet mail to appropriate mail hosts and user mailboxes. The format of an Internet address is username@Internet DNS domain name. Any email message routed across the Internet must adhere to this format.

Following is an explanation of the portions of an Internet email address:

  • Internet username: The username (or user ID) portion is an identifier for a mailbox in a mail system. For example, edekorte is the username for Erno de Korte. The username portion of an Internet address is typically controlled at the company or Internet service provider (ISP) level. Usually, companies or organizations specify a standard method for creating usernames, often using portions of users' full names. In this book's sample company, WorldWide Widgets, the naming standard for creating usernames is to use the first letter of the first name and follow it with the last name, without spaces.

  • Internet domain name: The domain name portion of an Internet address is the string on the right side of the address following the @ sign. This string identifies the mail host that Internet users must reach when sending to a particular organization. For example, the username edekorte belongs to the domain name wwwidgets.com, so Erno de Korte's fully qualified Internet address is edekorte@wwwidgets.com.

    Usually, domain names are based on the actual company or organization name. In the example of this book, WorldWide Widgets is the company name, and the domain name that refers to WorldWide Widgets on the Internet is wwwidgets.com. When selecting a domain name, an organization has to pick a unique name and register that name so that no other organization will use it.

  • Domain name registration: All registered domain names can be resolved through a domain name server (DNS). Domain names are registered through an organization called Internic. A DNS resolves domain names to show the actual Internet protocol (IP) address of the mail hosts that an organization uses to send and receive Internet mail. The DNS takes a domain name, which is like a zip code in the postal system, and translates it into an IP address of a mail host, which is like a local post office that handles mail for that domain.

    Tip

    Information regarding Internic, as well as information about how to register a domain name, can be found at www.internic.org.

  • Guaranteed uniqueness: The great value of having a central body such as the Internic in charge of domain names is that all domain names are guaranteed to be unique. Because the domain names are guaranteed to be unique, fully qualified Internet addresses are also guaranteed to be unique. For example, two users who have a common username will still be uniquely identified on the Internet, as long as the domain portion of the Internet address makes the entire Internet addresses unique. There are countless postmaster mailboxes on the Internet, but they are uniquely defined by the fact that their domain names are different.

All valid Internet email addresses will have the elements explained, no matter which email system is being used.

Understanding Old-Style GroupWise Addressing Format

Tip

This section will help you to better understand the way GroupWise used to handle Internet addressing, and this knowledge might be very useful for your understanding of the system and your troubleshooting. However, if you just want to quickly set up "modern day" Internet addressing, you can skip this section for now and move on to the section "Benefits of GroupWise Internet Addressing."

A basic characteristic of Internet addresses is that the address is ordered from general to specific as the address is resolved from right to left. The most specific part of the address is the username, on the far left. The most general part is the upper-level domain name (for example, .com or .net) on the far right. Processes that read and resolve Internet addresses read backward compared to the way you are reading the text of this book. They start on the right side and work their way to the left.

In contrast, old-style GroupWise addresses (prior to GroupWise 5.5 with Internet addressing) are resolved from left to right. They are still resolved from general to specific, though. This GroupWise address format is Domain.PostOffice.User (DPU). Note that a GroupWise domain is not the same as an Internet domain. GroupWise domains are created and named by GroupWise administrators, and they do not need to be unique worldwide. There is no central naming authority for GroupWise domains.

The fact that GroupWise domains are not unique didn't matter until companies that had common domain names began to connect to each other. To make the mail between their systems routable, each company would have to alter the name of the external domain definitions they created so that their address books would not show two CORP domains, for example.

As Internet connectivity became more and more common (almost as common as television!), GroupWise users realized that they had to know two addressing formats, one for users on their GroupWise systems and a different one for users elsewhere on the Internet.

True Internet addresses, in which every name is guaranteed to be unique, leave no question as to what domain a piece of mail should be routed to, regardless of where the piece of mail originated. To communicate through the Internet, GroupWise had to conform to the standards of Internet addressing to allow GroupWise mail hosts to communicate with other Internet mail hosts.

Old-Style GroupWise Internet Address Resolution

"Old-style" refers to any GroupWise system that does not have GroupWise Internet addressing enabled. This means all versions of GroupWise before GroupWise 5.5 (on which the option was not available), as well as any GroupWise 5.5x to GroupWise 7 system on which Internet addressing is not yet turned on.

As discussed in Chapter 10, "Installing and Configuring the GroupWise Internet Agent," GroupWise systems connect with the Internet through the GroupWise Internet agent (GWIA). This gateway allows GroupWise users to send email to Internet users by acting as a mail host and as an address resolver. The GWIA converts GroupWise addressing formats to Internet addressing formats, and resolves Internet addresses to GroupWise addresses.

The gateway also acts as a mail host to physically send and receive mail from the Internet. The GWIA stamps the outgoing mail with an Internet-style return address. Incoming mail is converted to a GroupWise address format. For example, a message sent from Corp.CorpPO.edekorte to an Internet recipient will have its reply-to address changed to edekorte@wwwidgets.com. An incoming mail message from the Internet will have its delivery address converted from edekorte@wwwidgets.com to a GroupWise address of Corp.CorpPO.edekorte.

Old-Style GWIA Creation of Reply-To Addresses

When mail is passing from the GroupWise system to the Internet, the GWIA has to create an Internet-standard reply-to address from the GroupWise information so that Internet recipients of GroupWise mail can reply. The gateway formulates the reply-to Internet address by using the rules shown in Figure 16.1.

Figure 16.1. The old-style GroupWise process for stamping reply-to on outbound messages, without Internet addressing enabled

[View full size image]

Here is a look at each of these reply-to addresses in turn, with each numeral in the following list corresponding to the number in Figure 16.1. We start at the upper-left corner of the diagram:

1.
If there is a fully qualified user Gateway alias for the GWIA (that is, the user alias has both a user portion and a domain portion), the reply-to address will be set to the user's alias. If Bob Snow's user Gateway alias is set to bobsnow@bob.wwwidgets.com, that will be his reply-to address.

Note

If a user has more than one alias for the GWIA, the first listed alias will always be used for constructing the reply-to address.

Tip

As a general rule, we do not recommend using Gateway aliases anymore, for reasons we will explain later in this chapter. The biggest issue is that these aliases will be "stamped" on the email going through this particular gateway, but the associated email address is not visible in the rest of your GroupWise system, in your eDirectory or in the address books.

2.
If there are a user alias and a post office alias, the reply-to address will be set to User Alias@Post Office Alias. For example, if BSnow's user alias is bobsnow, and the post office alias for his post office is sales.worldwidewidgets.com, the email he sends will be stamped with bobsnow@sales.worldwidewidgets.com in the reply-to field.

3.
If there is a user alias but no post office alias, the reply-to address will be set to User Alias@Foreign ID of GWIA. If the GWIA has more than one gateway foreign ID set, the first one on the list will be used.

Tip

The GWIA's gateway foreign ID is defined under the properties of the GWIA. Figure 16.2 shows the Foreign ID field on the WorldWide Widgets GWIA. A GWIA can have multiple foreign IDs. The first foreign ID is the default foreign ID for the GWIA. Foreign IDs are separated (delimited) with a single space. The Foreign ID field on the GWIA cannot exceed 124 characters. If you have several foreign IDs, create an ASCII file in the DOMAIN\WPGATE\GWIA directory called FRGNAMES.CFG. List the main domain name, such as worldwidewidgets.com, on the first line. List each of the other domain names, such as sales.worldwidewidgets.com, on a line by itself. Put a blank line at the end of the file. Restart your GWIA so that it reads this file.

Figure 16.2. The Foreign ID field for the GWIA must be filled in

[View full size image]

4.
If there is no user alias, but there is a post office alias, the reply-to field will be set to GroupWise UserID@Post Office Alias.

5.
If there is no user alias, and there is no post office alias, the reply-to address will simply be GroupWise UserID@Foreign ID of GWIA. This is the default case. A GWIA must have a foreign ID specified, and users must have a user ID; but aliases are not required.

Old-Style GWIA Resolution of Inbound Internet Addresses

Figure 16.3 shows what happens when a message is coming inbound to the GWIA.

Figure 16.3. Old-style GWIA inbound message resolution

[View full size image]

Inbound Internet mail arrives at the GWIA when a foreign mail host connects to the GWIA and sends something in on port 25. Typically, this happens because the foreign host found an MX record (DNS mail exchange) matching the GWIA up to the domain portion of an address. If DNS says that worldwidewidgets.com resolves to the IP address of the GWIA, any message to any user at worldwidewidgets.com will get sent to that GWIA.

This means that your GWIA could receive mail that is not destined for your GroupWise system. The GWIA needs to be able to deal with this situation. The rest of this section describes how mail coming through a GWIA is resolved to a GroupWise user address.

We start again at the upper-left corner of the diagram. First, the gateway compares the domain name of the message recipient with all the foreign IDs of the gateway. This is where the GWIA is checking to see whether the mail is actually destined for your system. If there is a match, begin with step 1; otherwise, begin with step 4:

1. | If a match is found, the GWIA checks to see whether the user portion of the recipient address matches a user alias. If so, the message is delivered to that user.
2. | If there is no user alias, the GWIA checks for matches with user IDs and nicknames. If a match is found, the message is delivered to that user.
3. | If no match is found for user aliases, nor for user IDs and nicknames, the message is undeliverable.
4. | If the foreign ID string of the gateway does not match the domain portion of the address, the GWIA determines whether there is a match with a fully qualified user alias (a user alias in which both the user and domain portions of the address are specified). If the GWIA finds a match, the message is delivered to that user. Tip We have seen situations in which step 4 of this algorithm did not work. It is just best to define all Internet domain names in the Foreign ID field or the FRGNAMES.CFG file.
5. | If there is no fully qualified user alias, but there is a match between a post office alias and the Internet domain portion of the address, the GWIA will not receive the message. By default, the GWIA does not allow relaying, and the Daemon portion of the GWIA will not be able to fully resolve the address; hence, it will drop the message.
6. | If there are no alias matches, and the foreign ID did not match, the message is not really destined for this GroupWise system. If message routing, or relaying, is enabled, the GWIA will attempt to pass the message on to the correct SMTP host.
7. | If message relaying is not enabled, the message is undeliverable.

Pitfalls with Old-Style GroupWise Addressing

Before discussing native GroupWise Internet addressing, this section explores the limitations of the old-style addressing. Following are the pitfalls of the old-style GroupWise address:

  • User training issues: With the prevalence of consumer Internet email, most users know how to address a message Internet-style. These users will want to be able to send to the Internet from GroupWise the same way they do from other email applications.

    Without GroupWise Internet addressing, these users must enter additional information to get their Internet messages out of the GroupWise system. Specifically, they must enter the domain and gateway name of the GWIA before the address, or they must enter the name of a foreign domain that has been associated with the GWIA. Thus, outbound messages are typically addressed internet:user@domain. A message simply addressed to user@domain will not make it out of the GroupWise system.

    GroupWise addressing rules can be used in place of true Internet addressing. This will alleviate the user training issues, but it won't help in other areas.

  • GWIA limitations: Another potential problem with this traditional handling of address conversion is that the gateway might only narrowly interpret incoming mail as being part of its GroupWise system. This limitation is primarily due to the way in which the GWIA looks at its Foreign ID field/FRGNAMES.CFG file. Addresses that don't match this field (or don't match user or post office aliases) might be marked undeliverable.

  • User alias limitations: A third problem lies in limitations of GroupWise user aliases. Only two addresses per gateway can be used to identify a GroupWise user. For example, Erno de Korte has a mailbox ID of edekorte and a user alias of erno.dekorte@worldwidewidgets.com. This means that his outgoing Internet mail will be sent to the Internet as being from erno.dekorte@worldwidewidgets.com, and he can receive email bound for the address of either edekorte@worldwidewidgets.com or erno.dekorte@worldwidewidgets.com.

Hopefully by now we've convinced you that you need to enable Internet addressing, which is discussed in the next section.

Benefits of GroupWise Internet Addressing

GroupWise Internet addressing offers several advantages over the old-style GroupWise addressing format. Following are some of the advantages of Internet addressing:

  • GroupWise addresses become true Internet addresses.

  • GWIA gains flexibility as it resolves Internet addresses to GroupWise users.

  • Client addressing rules might no longer be needed.

  • GroupWise systems can connect to each other natively, without defining external domains.

  • Certain features of GroupWise require Internet addressing.

Here is a discussion of each of these in turn:

  • GroupWise addresses become Internet addresses: With native Internet addressing, GroupWise addresses no longer need to be converted to Internet addressing formats when GroupWise mail is being sent out to the Internet. Instead of users being known internally to the GroupWise system as Domain.PostOffice.User, users will be internally known as UserID@Internet domain name.

  • GWIA gains flexibility: With Internet addressing enabled, the GWIA will work very hard to match an Internet address with a GroupWise user for incoming SMTP mail. The gateway will still look for the old-style matches with aliases and foreign IDs, as well as the following Internet domain name formats:

    • Full: User.PostOffice.Domain@Internet domain name

    • Post office unique: User.PostOffice@Internet domain name

    • User ID unique: User@Internet domain name

    • First, last: FirstName.LastName@Internet domain name

    • Last, first: LastName.FirstName@Internet domain name

    • First initial, last name: Firstinitial.LastName@Internet domain name

    • Free-form Internet address: Any RFC-compliant characters@Internet domain name

    Tip

    The free-form Internet address format was new to GroupWise 6.5 and is of course still available in GroupWise 7. This is not enabled at the system level as the other formats are. It can be implemented as an override option at the user level. For the free-form Internet address override to work, the user's post office and domain, and your GWIA, must be at GroupWise 6.5 or 7. If any of these agents is not at version 6.5 or 7, the free-form address might not work properly. Also, if the post office is not at version 6.5 or 7, the ConsoleOne snap-ins do not even display the free-form field for you to use.

    The term Internet domain name is specific to GroupWise Internet addressing. The Internet domain name is an extra attribute attached to every address in GroupWise, and therefore makes GroupWise addresses comply with Internet address formats.

    Note

    Internet domain names are sometimes referred to as IDOMAINs. This term might help avoid confusion.

  • Client addressing rules are no longer needed: When Internet addressing is enabled, client addressing rules are no longer needed to route mail messages to the Internet. Because GroupWise addresses are Internet addresses, mail addressed Internet-style will be correctly routed to the GWIA without the explicit address of the GWIA.

    Also, turning on Internet addressing will enable GroupWise users to send to other internal GroupWise users or external Internet users by simply typing the Internet address, such as UserID@Internet domain name. Internet addressing removes the need for addressing rules that search for an Internet-style address and replaces the address with a GroupWise gateway:internet address or with an external foreign domain:internet address.

  • Direct MTA-to-MTA connectivity between systems: With Internet addressing enabled, you can allow any message transfer agent (MTA) on your system to connect directly to another GroupWise system. The GroupWise message transfer protocol (GWMTP) allows GroupWise users to transparently communicate over the Internet with other GroupWise users in other systems.

    GWMTP sending effectively eliminates the need to convert messages bound to other GroupWise systems. No gateway or gateway conversions are needed for the two systems to communicate. Leaving the messages in their native format also allows for native GroupWise encryption, compression, and message formats to be retained. Keeping the native message type allows appointments to be sent to users in other GroupWise systems as appointments. These items will show up correctly on calendars, and can be accepted or rejected, and full status tracking is available. The native format also allows for busy searches across the Internet GroupWise systems. You can find more about this in Chapter 34, "Creating a GroupWise-to-GroupWise Communication Solution Across the Internet."

  • Future GroupWise enhancements will require Internet addressing: Several GroupWise features require Internet addressing to be turned on. One current GroupWise feature that requires Internet addressing is Junk Mail Handling.

  • Third-party solutions will require Internet addressing: User and Post Office Gateway Aliases are stamped at the gateway level and are not shown in eDirectory, the GroupWise Directory Store (Domain and Post Office databases), which is the basis for the GroupWise System address book. Imagine the problems for a third-party developer if he cannot simply rely on the fact that the Internet email address of a user is properly stored in eDirectory or in the GroupWise Directory Store.

Although when you install GroupWise it does not require you to enable Internet addressing, you should enable it as soon as possible.

Potential Pitfalls in Enabling Internet Addressing

Tip

If you have created a new GroupWise system or have used Internet addressing before, the next section might be of interest only as a means for you to fully understand all the issues. If you're not really interested, you can skip this section and move on to the section "Enabling Internet Addressing."

GroupWise functionality is becoming entrenched in Internet addressing. It is likely that you will eventually have to enable it for full functionality. Unfortunately, enabling Internet addressing is not without a few potential hazards, including these:

  • Personal address books are converted to Internet address formats.

  • Legacy clients like the GroupWise 5.2 Mac client, which is sometimes still used, need to use this old addressing format.

  • Client Internet addressing rules are no longer used.

  • Turning off Internet addressing isn't really an option.

The following discussion goes over each of these issues in turn:

  • Address-book conversion to Internet address formats: When Internet addressing is enabled, users' address books will be converted to Internet addressing format for the email address column. This means that gateway names will be removed, as will foreign domain names.

    In some circumstances, we have seen the conversion process fail for some addresses. You might want to be alert to delivery problems for the first few weeks after Internet addressing has been enabled.

  • Legacy clients still use the old addressing format: You might have GroupWise 5.2.7 Macintosh clients on your 6.x post offices. These clients need to use the old addressing scheme.

    For these legacy clients, you will need to maintain your foreign domain names (for Internet-style addressing), as well as your addressing rules.

  • GroupWise 5.5x and GroupWise 6x clients ignore some addressing rules: When Internet addressing is enabled, all GroupWise 5.5x and GroupWise 6x 32-bit clients will no longer use certain addressing rules. If a rule executes on address strings that contain an @ sign followed by a dot (.) and replaces it with a string that includes a colon (:), that rule will be ignored.

    For example, an addressing rule that searches for *@*.com and replaces that string with inet:%1@%2.com will be ignored by the 5.5x and 6x clients when Internet addressing is enabled.

    This should not be a problem, but it is possible on large systems that addressing rules meeting these criteria will still be needed for some reason or another.

  • Turning off Internet addressing can be painful: The biggest disadvantage to enabling Internet addressing is that you cannot really back out of it.

If you do have problems enabling Internet addressing, seek technical support help rather than attempting to turn it off.


Enabling Internet Addressing

There are three things you have to configure to enable Internet addressing:

  • Default GWIA

  • Default Internet domain name

  • Preferred addressing format

All of these must be configured in the Internet Addressing window shown in Figure 16.4.

Figure 16.4. The Internet Addressing dialog box

Selecting the Default GWIA

First, start with the default GWIA. Before you can select the default GWIA, you must have installed the GroupWise Internet Agent somewhere on your system. See Chapter 10 if you do not yet have a GWIA installed on your system.

Following are the steps for selecting the default GWIA for a GroupWise system:

1. | Choose Tools, GroupWise System Operations, Internet Addressing. The window shown in Figure 16.4 appears.
2. | Populate the field labeled Internet Agent for Outbound SMTP/MIME Messages using the drop-down list. All GWIAs on your system should appear on this list.

A default GWIA must be assigned so that mail that is not deliverable locally, or that cannot be resolved through GWMTP, will be automatically routed to the GWIA. This automatic routing is what allows the client Internet addressing rules to become obsolete. You don't need to specify the GWIA in the message address, because it has been specified system-wide here.

Selecting a Default Internet Domain Name

Now enter a domain name. This must be the name your organization uses on the Internet. It will probably be the first foreign name configured for your GWIA in the Foreign ID field or FRGNAMES.CFG. Following are the steps for selecting a default Internet domain name:

1.
From the Internet Addressing window, click Create to call up the window shown in Figure 16.5.

Figure 16.5. The Internet Domain Name dialog box is where you enter a new Internet domain

Tip

Internet domain names cannot be created until a default GWIA has been selected.

2.
Enter your organization's Internet domain name, including upper-level domain names (that is, enter company.com rather than just company).

3.
Enter a description for this domain name, if desired.

This might be useful if you plan to have more than one Internet domain name.

4.
Click OK.

You have now enabled Internet addressing and/or defined a new Internet domain that your GroupWise system recognizes.

Choosing a System-wide Preferred Internet Addressing Format

A preferred Internet address format can be specified after a default GWIA and Internet domain name have been set. The preferred addressing format defaults to userid@Internet domain name, but it can be configured to one of several settings.

The Internet addressing format will then be used as the default username format that the GWIA stamps on all outgoing mail. This format also determines how addresses appear in the GroupWise address book. This format will not be used for resolving routes on inbound email. Users' Sent Items properties will also show the Created By field in this format instead of the legacy User.PostOffice.Domain format.

Following are the steps for setting the preferred system-wide default for the Internet addressing format:

1.
From the Internet Addressing window, pull down the Preferred Address Format list shown in Figure 16.6.

Figure 16.6. The Preferred Address Format pull-down menu allows you to set the system-wide Internet addressing format

2.
Select the format that best suits your organization's needs.

Most organizations find that userid@Internet domain name works best. The reasoning behind this addressing format is discussed in the section "Best Practices," later in this chapter.

Identifying Acceptable Address Formats

You can also select which addressing formats are allowed in your GroupWise system. By default, when you enable Internet addressing, all address formats are enabled except first-initial, last-name format. These addressing formats allow users to receive mail in this format as well as the preferred address format you selected previously.

For example, if your preferred address format is userid@Internet domain name, and you had the first.last format enabled, users could be addressed as either userid@Internet domain name or first.last@Internet domain name. The first and last names are defined on the eDirectory user object for each user, so it is important that this information be correct in eDirectory.

You will also notice that you can enable or disable the system from trying to resolve first-initial, last-name format in your system. Using first-initial, last-name format can be useful if your GroupWise userIDs are not user friendly. For example, if your userID is 12345abc, you probably don't want to have your users use this as the addressing format. You might want to choose first-initial, last-name format such that a user of Erno de Korte would be addressed as "ede korte" (but watch the space in the last name; we will have to fix that, as discussed later in this chapter). Once again, the first-initial, last-name fields are pulled from the eDirectory user object's first- and last-name fields. Unless you have a need to resolve first-initial, last-name formats, it is not recommended to use this format. The chance of having duplicate userIDs increases with this format. This is why you can disable this format from being resolved in the GroupWise system.

Internet addressing is now enabled with these settings system-wide. You can override some of the settings you made here at the domain, post office, or even user level. These options are discussed shortly, in the section "Internet Addressing Overrides."


Enabling MTA-Direct Connectivity (GWMTP)

By setting up Internet addressing like this, we've not only enabled the Internet Agent (GWIA) to use this format, but also allowed our MTAs to connect directly to each other, connecting your GroupWise automatically to any other GroupWise system and thereby exchanging GroupWise information on a much higher level than the basic SMTP level. This option is discussed in much greater detail in Chapter 34.


Internet Addressing Overrides

After Internet addressing has been enabled, customizations or overrides can be used to increase the flexibility of Internet addressing within the GroupWise system. Overrides can be enabled on the Internet Addressing tab on the detail screen of domains, post offices, and users.

Internet Domain Name Overrides

Overrides at a domain, post office, or user level can be used to specify a certain Internet domain name. For example, the sales division in the Sales GroupWise domain might want to be known as sales.worldwidewidgets.com rather than just worldwidewidgets.com. An override can be set on each domain to allow all members of each domain to have the specific Internet domain name value. If the members of a post office wanted a specific Internet domain name for their post office, an override could be done for that post office through the Internet Addressing tab on that post office object's properties window.

Note

All Internet domains that your organization wants to use need to be defined in two places. First, they should be defined in the Internet Domain Names section under Tools, GroupWise System Operations, Internet Addressing. Second, your Internet domains should be defined, for the sake of the GWIA, in the Foreign ID field or the FRGNAMES.CFG file explained earlier in this chapter. Having all Internet domains defined in the Foreign ID field on the GWIA is not critical. If the /dia switch in the GWIA.CFG file is not being used, the GWIA reads all IDOMAINs from the domain database to find out its identity, if you will. However, if the /dia switch is active on the GWIA, it will not read the domain to get the list of known IDOMAINs, and will strictly use the foreign ID names for building reply-to addresses, both inbound and outbound. It will not honor the overrides at the domain, post office, or user level when the /dia switch is in use on the GWIA.

The last type of Internet domain name override happens at the user level. If a user or group of users wants a different Internet domain name than the one being used at the system, domain, or even post office level, you would use the Internet Addressing tab on those users' user objects.

Preferred Addressing Format Overrides

Domains, post office, and user objects can also have overrides to specify a preferred addressing format. This means that while the system default for preferred addressing format can be set to userid@Internet domain name, any domain, post office, or user can have one of the other available preferred addressing formats (such as first.last@Internet domain name).

Tip

Even though you select a preferred addressing format, users can receive mail at any of the allowed addressing formats defined at the system, domain, post office, or user level. This preferred format just determines what the reply-to address format is. Hence, Billy Bob could receive mail at billy.bob@wwwidgets.com, bbob@wwwidgets.com, bob.billy@wwwidgets.com, and so on if these formats have not been disabled at the system, domain, post office, or user level. If you want to prevent Billy Bob from receiving mail using the other formats, you can simply disable a particular format at the system, domain, post office, or user level.

You can also override the actual Internet email address at the user level. You can use a free-form type of address that allows you to type the user's email IDs that they want to use. This is actually the solution we can use to correct the problem with spaces or upper ASCII characters in first-name or last-name eDirectory fields. Let's have an example that is a bit like one you've seen earlier: The first name of this user is Remon and the last name is de Korte. With the Internet addressing at first.last@Internet domain name, that would become Remon.de Korte@Internet domain name. This example shows two problems: spaces and upper ASCII characters, which are in general not acceptable in Internet email addresses.

The override feature is designed to correct these issues without the need to use gateway aliases on the GWIA. You can simply select the Override option and add the desired name in the Override field, as shown in Figure 16.7.

Figure 16.7. The Internet Addressing property page for the user allows you to override the user's Internet address

[View full size image]

So if you have been using Gateway Alias records, you can now replace these with the free-form Internet address override at the user level. Remember that the user's post office must be version 6.5 or 7 for you to see the Override option in ConsoleOne.

Default GroupWise Internet Agent Overrides

On a large GroupWise system, there might be more than one point at which the system connects to the Internet. Novell's corporate network is an example of this point. They maintain permanent Internet connections for their corporate offices in Boston, Massachusetts, and in Provo, Utah, as well as in many of their regional offices.

In these cases, it makes sense to allow regional domains to route Internet mail through a local GWIA, instead of forcing all messages through the default GWIA. Domain objects have an Internet agent for outbound SMTP/MIME messages override, allowing the system administrator to select from any GWIA defined on the system. Figure 16.8 shows the property page of a GroupWise domain object that allows you to override the system-level Internet addressing format.

Figure 16.8. The Internet Addressing property page allows you to override the system-wide Internet addressing format

[View full size image]

If you have defined a default routing domain at the system level, you cannot override the Alternate Internet Agent for Outbound SMTP/MIME Messages option.


Mail Routing with Internet Addressing Enabled

Now that you understand the concepts behind GroupWise Internet addressing, this section discusses the flow of email through an Internet addressingenabled GroupWise system.

Outbound Email

Internet addressingaware (or IA-aware) clients (GroupWise 5.5x and newer clients) allow mail with Internet addresses to be routed internally or to Internet users without the use of addressing rules or external domain definitions. Without Internet addressing enabled (and no addressing rules in use), messages sent to users with Internet-style addresses are flagged as undeliverable when mail is sent from the client.

With Internet addressing enabled, the client performs less lookup on recipient addresses. Messages with Internet-style addresses are pushed on by the client to be resolved by the POA, MTA, or GWIA. Note, though, that each component in an IA-aware GroupWise system is capable of parsing Internet address information to some extent, including the GroupWise client. Each component (client, POA, MTA, and GWIA) will do the best it can to resolve the address from its perspective.

If the POA cannot resolve an address, it pushes the message to the domain MTA. If the message is addressed to an Internet address, and the domain MTA cannot resolve the message to one of its post offices or an address internal to the system, the message will be routed to the default routing domain for a GWMTP lookup by the MTA there (you can find more on GWMTP in Chapter 34). If the recipient address cannot be resolved with a GWMTP DNS lookup, the message will be routed to the default GWIA for transfer to the Internet.

Inbound Email

When a message arrives at a GroupWise system from the outside world, it does so in one of two ways:

  • Direct MTA-to-MTA transfer via GWMTP (see Chapter 34)

  • SMTP/MIME transfer via the GWIA

Note

Messages can also come in through another GroupWise gateway, but typically those are not going to be outside-world messages. Most other gateways, such as the Exchange gateway or the Lotus Notes gateway, are handing explicitly addressed messages to the GroupWise MTA, so the messages can be treated as internal to the GroupWise system.

When a message comes in via GWMTP, the MTA receiving the message will process the message by sending it to the GroupWise domain within the GroupWise system of which the recipient is a member. The recipient's domain routes the message to the recipient's POA, which delivers the message to the recipient's mailbox.

When a message comes in through the GWIA, via SMTP/MIME, it is processed with the flow described in Figure 16.9. The GWIA checks the domain portion of the recipient address for user alias, post office alias, foreign ID, or Internet domain name matches. If GWIA does not find a match for the recipient domain address, it will route or relay the message to an appropriate Internet mail host for the specified domain, or it will send an undeliverable message back to the sender.

Figure 16.9. An example of the parsing and lookup process

[View full size image]

Assuming that a match was found (that is, the message must be delivered to this GroupWise system), the second level of resolutions involves checking the username portion of the recipient mail address to determine whether a unique match can be found.

Note

The GWIA is fully backward compatible for resolving traditional GroupWise addressing, in addition to using the flexible rules of Internet addressing resolution.

This section explores this address resolution process in more detail.

Following is the logic that the GWIA uses in routing in-bound Internet email:

1.
Compare user@domain (the entire string, not just the user portion) against user Gateway aliases defined at the GWIA. If there is a match, the message can be passed directly to the MTA to be routed to the user. If there is no match, move to step 2.

2.
Compare the user portion of the address against user Gateway aliases defined at the GWIA. If there is a match, move to step 3. If not, move to step 4.

3.
Compare the domain portion against post office aliases, Internet domain names, or foreign IDs defined for this system or assigned to the GWIA. If there is a match, the message is passed to the MTA to be delivered. If not, the message does not belong to this GroupWise system and will be passed to the Internet (or passed to another host if the GWIA is configured to allow the feature called Forward Undeliverable Inbound Message to Host). Otherwise, the message is discarded.

Note

If the message arrived at the GWIA from the MTA (that is, it came from inside the system), it will still be checked to determine whether it belongs on this system, using steps 1 through 3. This is how messages addressed by non-IA-aware components to recipients on this system are handled.

4.
Does user@domain match up with a UserID@Post office alias string? If so, the message is passed to the MTA for delivery. If not, go to step 5.

5.
Compare the domain portion of the address against the Internet domain names defined on the system and against the foreign ID assigned to the GWIA. If there is a match, move to step 6. If not, the message is delivered to the Internet.

Note

Steps 1 through 5 checked out aliases, which are shortcuts to address resolution. Anything that makes it to step 6 is not going to match up to a user or post office alias, but does match up with this system's Internet name or names.

6.
After the message is known to belong to the system, a parsing engine tries to uniquely resolve the user portion of the address with a GroupWise user. The parser engine compares the user portion of the recipient address (everything on the left side of the @ symbol) with the following GroupWise information:

  • Free Form/User Override set: The contents on the left of the @ sign are checked for any matches defined on the Internet Addressing properties page of a user object. The free-form override setting is one way to give a user an Internet address that does not comply with the system defaults. This setting is on the Internet Addressing properties page of any user object. The free-form field is the second field below the Preferred Address Format field. If a match is found here, the system has a unique match. For an example, take a look at Figure 16.7.

  • UPD resolution: The address is parsed and compared against the address book for matches in User.PostOffice.Domain format. If the user portion has fewer than three segments (that is, there aren't two dots in the user portion), it will be compared in User.PostOffice, or just User, format.

  • DPU resolution: The address is parsed and compared against the address book for matches in Domain.PostOffice.User format. Again, if the string is not long enough, it will be compared in PostOffice.User format.

  • Name-based resolution: The address is parsed and compared against the address book for matches to FirstName.LastName, LastName.FirstName, and FirstinitialLastName.

Note

FirstinitialLastName format is not enabled by default in a GroupWise system, and will not be looked up unless the administrator has enabled it.

7.
If there are no matches for the parsed user portion of the address, the message becomes undeliverable. If there are matches, even partial matches, move to step 8.

8.
A preference filter is applied, and if the parsed address is unique at any level of preference, it is delivered. Partial addresses are passed to the MTA for complete resolution at the MTA or POA level. If the parsed address is not unique, the message is undeliverable.

The process that the GWIA uses to get a message to a recipient is quite complex. The flexibility that GroupWise gives you for defining a user's address format is what makes the process so complex.


Understanding the Parsing and Lookup Process

In the flow in the preceding section, the GWIA reached a point in step 6 where it had to parse the user portion of an Internet-style address, and then perform a lookup to determine whether there were any matches. It is important that you understand the rules behind the parse and lookup, because they will affect the decisions you make when implementing Internet addressing on your GroupWise system.

Every component on an IA-aware GroupWise system can perform the parsing and lookup operations described next and outlined in Figure 16.9. When messages come in to the system through the GWIA, the GWIA parses and looks up. Messages coming in through the MTA via GWMTP will have their addresses parsed and looked up by the MTA.

In the process shown in Figure 16.9, an Internet-style address has been handed to a GroupWise component, and that component has reached the point where it must parse the user portion of the address. The balance of this section explores the process.

Following is the parsing process that GroupWise uses to determine the correct recipient of a message:

1. | GroupWise begins with a parse and lookup for matches in UPD (User.PostOffice.Domain) format. If the user portion of the address has fewer than three components, GroupWise will perform a User.PostOffice or a user lookup. If there is one and only one match, GroupWise delivers the message. If there is more than one match, GroupWise goes to step 3. If there are no matches, GroupWise continues with Step 2.
2. | GroupWise now parses and looks for matches in DPU (Domain.PostOffice.User) format. This is the legacy addressing format used by GroupWise. Again, if there are fewer than three components to the user portion of the address, GroupWise will perform a PostOffice.User lookup. There's no need to do a user lookup, thoughGroupWise did that in step 1. If there is one and only one match, GroupWise delivers the message. If there are multiple matches, GroupWise goes to step 3. If there are no matches, GroupWise goes to step 4.
3. | Messages will be delivered to the closest match. If one of the matches is on the same post office as the component doing the parsing and lookup, that match will be chosen above other matches. If there is only one preferred match, the message will be delivered. If there is more than one match (that is, there are no preferred matches), the message becomes undeliverable or ambiguous. If the GWIA, the POA, or the MTA reaches this point, the message is undeliverable. If the client reaches this point, however, the user might be prompted to resolve the ambiguity.
4. | GroupWise now checks the usernames. GroupWise looks for matches in First.Last, Last.First, Firstinitial.Last, and three-part name format and will check all possibilities at once. If there is one and only one match, the message is delivered. If there is more than one match (for example, the message is addressed to James.Howard, and you have a Howard James and a James Howard on the system), the message is ambiguous or undeliverable. No delivery preferences are applied. If there are no matches, the message becomes undeliverable.

Parsing Usernames

It might be helpful at this point to look deeper at step 4 from the preceding section. Here is the logic followed when a GroupWise component parses the user portion of the address for matches with users' full names:

1.
Replace all periods left of the @ sign with spaces.

2.
If there is more than one space, see step 7.

3.
Assign the text left of the space to Part_A.

4.
Assign the text right of the space to Part_B.

5.
Search the given and last names for all users in the GroupWise system. Compare the following combinations, and select all matches:

Given=Part_A
Last=Part_B

Given=Part_B
Last=Part_A

6.
Skip to step 11.

7.
Assign the text left of the first space to Part_A.

8.
Assign the text between the first space and the second space to Part_B.

9.
Assign the rest of the text to Part_C.

10.
Search the given and last names for all users in the GroupWise system. Compare the following combinations, and select all matches:

Given=Part_A
Last=Part_B Part_C

Given=Part_A Part_B
Last=Part_C

Given=Part_C
Last=Part_A Part_B

Given=Part_B Part_C
Last=Part_A

11.
If no matches exist, skip to step 16.

12.
If a unique match is found, skip to step 17.

13.
External users who match are eliminated if internal matches exist.

14.
Matches outside the local GroupWise domain are eliminated if matches exist in the local GroupWise domain.

15.
If a unique match is found, skip to step 17.

16.
The message is undeliverable because no match is found.

17.
Deliver the message.

Understanding parsing scenarios is most likely to be important in larger GroupWise systems, and in GroupWise systems that do external system synchronization with one another.

Parsing Scenarios

Here are a couple of sample scenarios to let you see how these pieces fit together, beginning with the following:

  • A message is addressed to mike.sales@wwwidgets.com.

  • User Mike Sales exists in the CORPPO post office.

  • There is a post office called Sales on the system somewhere.

  • No user or post office aliases exist.

Here's what will happen. The GWIA for WorldWide Widgets will decide that the message belongs on this system and will attempt to resolve the user portion of the address. Now walk through the logic in the following steps:

1. | The string mike.sales is compared against the address book for UPD matches. Because there are only two parts to the string, it compares mike for user matches and sales for post office matches.
2. | A partial match is found. There is a post office called sales on this system.
3. | The message is routed to the sales POA for resolution of the remainder of the address.
4. | The sales POA looks for a user ID mike on the local post office and finds none. The message is undeliverable. Note here that having post office names that match usernames can cause problems for messages addressed in First.Last or Last.First format.

And now for the second scenario, note the following:

  • A message is addressed to marcel.de.korte@wwwidgets.com.

  • A user with the first name Marcel and the last name de Korte exists in the CORPPO post office.

  • No user or post office aliases exist.

In this case, the GWIA for WorldWide Widgets will end up attempting to resolve the user portion of the address as a three-part name:

1.
The GWIA looks for a user ID marcel on the post office de in the domain korte. No matches are found. The names de and korte do not match any post office or domain names on this system.

2.
The GWIA looks for a user ID korte on the post office de in the domain marcel. No matches are found. The names de and marcel do not match any post office or domain names on this system.

3.
The GWIA looks for users with the following names:

First=Marcel, Last=de Korte
First=Marcel de, Last=Korte
First=Korte, Last=Marcel de
First=de Korte, Last=Marcel

4.
One match is found, and the message is delivered to user Marcel de Korte.


Best Practices

Internet addressing is increasingly important to GroupWise administrators, so we encourage you to enable it and not to use Gateway aliases anymore. Before you do, however, you should be sure to carefully plan your Internet addressing implementation to avoid potential pitfalls. This section outlines some of the practices that administrators use successfully.

Naming Conventions

Following are a few tips to keep in mind as you plan your Internet addressing strategy:

  • Strive to make all user aka mailbox IDs unique throughout the GroupWise system. GroupWise administrator will require user IDs to be unique only per post office, so you will need a separate tool to ensure that you are not duplicating a user ID.

  • Use userid@Internet domain name as your preferred addressing format. The preferred addressing format is used to build the reply-to address, and if user IDs are unique system-wide, this format allows you to move users to any post office on your system without their Internet address changing. This setting will prevent reply-to addresses that are ambiguous in cases in which first- and last-name combinations are not unique.

  • If user IDs cannot be unique, avoid using Internet domain names to make an Internet address unique within the same GroupWise system. If Internet domain names are making the user portion of a local Internet address unique, the exclusive flag must be set on users who do not have unique user portions for their Internet addresses. This will mean that the user might be known only by the particular addressing format and Internet domain name. It also means extra work for the administrator. If user IDs cannot be unique, it will likely be easier to use the override option at the user level to define a free-form Internet address.

    Note

    With GroupWise 7, you can now use the same Internet email ID (the portion before the @ sign) for more than one user in your GroupWise system, provided that each user is in a different Internet domain. Rather than requiring that each Internet email ID be unique in your GroupWise system, each combination of Internet email ID and Internet domain must be unique. This provides more flexibility for handling the situation in which two people have the same name.

    However, we still recommend staying away from this option if possible and creating unique Internet email IDs if possible, because this will make your troubleshooting much easier.

  • User IDs, first names, and last names should not be the same as post office or domain names. (See the first scenario in the section "Parsing Scenarios," earlier in this chapter.) One easy solution for this problem is to include numbers or underscores in post office and domain names.

  • Users should have no more than three names embedded in their complete name. "Marcel de Korte" is okay, but "Sir Marcel de Korte" is not. Think of it this way: You can have a space in either the first-name or the last-name field, but never in both fields. Only the first name or the last name can have a space in the name.

  • Users cannot share the same first and last name or user ID unless each of the users has a unique Internet domain name and the exclusive flag is specified on the Internet addressing tab for each of the users. The exclusive flag will allow each user to be known only by the specified Internet domain name, thereby guaranteeing that the users' Internet addresses are unique.

  • When used, user Gateway aliases and nicknames should be unique throughout the system. We recommend eliminating Gateway aliases on all users within your GroupWise system. Gateway aliases on users defined under external domains are fine.

  • If you intend to send messages via S/MIME or PGP/MIME, do not use Gateway aliases. Rather, use free-form Internet addresses. When an S/MIME or PGP/MIME certificate has an email address that differs from the From field of an SMTP message, the message is considered invalid. Eliminating Gateway aliases resolves this potential problem.

The key here is to move toward unique Internet addresses. You should consider using the Email Address Lookup feature on the GroupWise Utilities menu in ConsoleOne to help you create unique addresses in your GroupWise system.

System Design

This section offers a few suggestions on effectively setting up GroupWise Internet addressing on your GroupWise system:

  • If direct MTA-to-MTA connectivity is enabled, the GroupWise domain that owns the default GWIA should be the default routing domain. This will simplify firewall administration (only one machine needs to be outside the firewall) and reduce traffic (you can find more about this feature in Chapter 34).

  • On large systems that span wide area networks, use default GWIA and default routing domain overrides to ensure that traffic bound to the Internet takes the most efficient route. (This assumes that your system has more than one connection to the Internet.)

  • If an external system (such as a UNIX mail host) shares your Internet domain name, enable the option Forward Undeliverable Inbound Messages to Host (found on the SMTP/Mime Undeliverable property page of the GWIA). See Chapter 10 for more details.

  • Ensure that all GWMTP-enabled MTAs can receive packets from their assigned port from the Internet and that they can send packets out to the Internet on high-numbered ports. See Chapter 34 for more details.

These system design suggestions are most relevant in large GroupWise systems (5,000 or more), of which there are many!


Summary

GroupWise Internet addressing is an essential piece of current and future GroupWise technology. Before implementing it, however, administrators must carefully consider their naming conventions and system design. You should also take message flow and parsing into consideration. An understanding of the way the system works will help the prudent administrator design or redesign a GroupWise system so that it is easily administered and maintained.


Chapter 17. Maintaining the GroupWise System

If you have implemented a good system design (discussed in Chapter 19, "Building Your GroupWise System Correctly"), regular maintenance of your GroupWise system can be automated. Through automation, it is possible to reduce the amount of time you spend functioning as an administrator.

If your users access the post office in client/server access mode, and you implement a few appropriately scheduled events, your chances of losing data due to information-store damage are minimized. This chapter covers the maintenance of the GroupWise information store and the GroupWise directory and walks you through the creation of some appropriate events to schedule.


Information-Store Maintenance Concepts

The GroupWise information storethe collection of databases and directory structures discussed in Chapter 4, "Understanding the GroupWise Information Store"is susceptible to damage, just like any other set of files on a server. The information store is written to thousands of times each day, and although the odds of any individual transaction failing are astronomically low, after enough reads and writes the odds begin to add up in favor of an occasional problem.

For the purposes of this discussion, really only two kinds of damage or corruption are possible:

  • Structural damage

  • Content damage

It is easiest to explain these categories using an analogy. Suppose that you have a filing cabinet, and each file in each drawer contains not only its own information but also references to other files. Then one day, a herd of rampaging elephants being chased by a swarm of mosquitoes charges through your office and dents the filing cabinet. One of the drawers will not open any more. This is structural damage.

Now, suppose that you fix the cabinet by transferring all the files you could get to from the dented cabinet into a new one. Unfortunately, you could not recover any of the files from the dented drawer. Later, when reading a file in one drawer, you see a cross-reference to a file in another drawer. You follow the cross-reference, but that referenced file is not there. This is content damage.

As you can see, structural damage can lead to content damage if not properly repaired. It's important for you to understand and remember this when dealing with the GroupWise message store.

Structural Maintenance

Your greatest concern regarding the GroupWise information store should be the structural health of the GroupWise databases. If there is a herd of elephants running around denting your databases, you need to know about it. You should take steps to ensure that all user and message databases on a post office are structurally analyzed and fixed every day. This is done via the Scheduled Events tab on the POA (Post Office Agent) object.

Content Maintenance

The contents of the GroupWise information store need to be verified on a weekly basis. The contents analysis ensures that the pointers from one record to another record are valid. The contents check-and-fix also ensures that master records (as discussed in Chapter 20, "Troubleshooting Message Flow") have pointers to the other supporting records for a message.

The Relationship Between Structure and Contents

As was illustrated in the example of the filing cabinet and the herd of elephants, one common reason for content-related problems is structural damage. Consider this scenario, for example:

USERA's USER123.DB file has a pointer to record #286 in MSG17.DB. Unfortunately, a large block of MSG17.DB is damaged (for example, the server abended while the file was being written to). The next time the POA works with this file, it detects the damage and the file is rebuilt. The damaged block could not be recovered, though, and record #286 is lost from MSG17.DB.

USERA's USER123.DB file now has a contents inconsistency. The contents analyze-and-fix routine will take the pointer in USERA's USER123.DB file and tie it off so that it points nowhere. This, in effect, makes the received item a posted item. USERA can still read the subject line and see who sent the message, but the message contents and any attachments are lost. USERA can contact the sender, having him or her resend or recompose the message, if necessary.

Contents Analysis Is Time-Consuming

Contents analysis can take a long time, especially if your post office is a large one, or if your users retain their messages indefinitely. If your information store is large, you will want to run your contents analysis over a weekend. We have encountered organizations whose GroupWise information stores were so large that a contents analysis for a single post office took well over 24 hours to run.

Email Expiration

Based on what you just learned, you can see part of the logic behind not allowing your users to keep their email forever. Thus, we strongly recommend that you implement an email expiration policy. You might choose to expire all email messages after they are 90 days old, but allow appointments to stay on the system for a full year. You might also decide to purge all deleted items (items in the trash) early each morning.

Justification for Email Expiration

The downsides to allowing a GroupWise information store to grow too large are the following:

  • Backup operations might not complete overnight, due to the sheer volume of data to be backed up.

  • Contents analysis takes a very long time.

  • QuickFinder indexing might take longer, and a QuickFinder index rebuild operation (executed from the POA console) will take much, much longer than you might have time for.

  • Larger information-store databases impede POA performance, which will in turn mean that your users will observe poorer performance from the GroupWise client.

These downsides are real! The time required to run a Mailbox/Library Maintenance on a post office with a large message store makes the operation so time-consuming that you may find that maintenance cycles cannot complete before regular business hours have resumed.

Overcoming Hurdles to Email Expiration

There are really only three reasons to keep an email message longer than 90 days:

  • Sentimental reasons: If this is the case, invite your users to use the GroupWise archive. They will still have access to the items, but they will not be impacting performance on the master mailbox. GroupWise archives should not be allowed to grow too much either. Maintaining archives can become a big issue. You should consider a third-party archive solution such as those available from the following Web sites:

    www.messagingarchitects.com
www.nexic.com
www.intellireach.com

  • Legal reasons: If email messages are considered legal documents in your company, consider writing your email policy in such a way that your backup tapes can be considered the legal record of these documents.

  • As a reminder of important information: Any email message that is still being read regularly after 90 days should probably become a GroupWise document (in a GroupWise library) or should be on your company's internal web page.

It is important to know why users want to keep their email for a long time. Knowing this will help you suggest alternatives. In short, if you approach the problem from the right direction, you should be able to implement an email expiration/archive policywith the blessing of your user community.

GWCheck/GroupWise Message Store Check

The software used to maintain and repair the GroupWise information store is commonly called GWCheck. This software actually resides in four places:

  • The post office agent: Each POA has the GWCheck code built into it. The code is launched when one of the following occurs:

    • Mailbox/library maintenance is run from ConsoleOne.

    • A scheduled event runs.

    • The POA detects a problem with a database it is trying to work with and kicks off a GWCheck job.

  • GWCHECK.EXE: Found in the Software Distribution Directory ADMIN\UTILITY\GWCHECK, this is the standalone GWCheck software. It runs as a Win32 application, so to run it you must have full file access to the information store from a computer with a Windows 32-bit operating system.

  • gwcheck: This is the standalone Linux GWCheck. The RPM for the Linux GWCheck is found in the admin directory of a Linux Software Distribution Directory. When GWCheck is installed, it can be found at /opt/novell/groupwise/gwcheck/bin.

  • The GroupWise client: The version of GWCheck built into the client does not fix a user's master mailbox, but it can fix archive, caching mode, and GroupWise remote message store databases.

The post officebased GWCheck can be automated to run GWCheck jobs on a scheduled maintenance routine. The standalone and client-based GWCheck cannot be automated.

Benefits of Running GWCheck on the POA

We often encourage our customers to use the POA-executed GWCheck. Here are some very good reasons to run mailbox/library maintenance, or to use scheduled events, instead of running the GWCHECK.EXE:

  • Speed: Assuming that the POA runs on the same box where the information store is located, the POA can run the GWCheck routines at least twice as fast as GWCHECK.EXE. It can run the operation right "on the bus" rather than across a network connection.

  • Stability: GWCHECK.EXE runs on the Windows platform and must run "across the wire." If something goes wrong on the workstation (GPF, blue screen of death, and so on), or if the LAN connection goes down, GWCHECK.EXE might do more harm than good. The POA is not as vulnerable in this way.

  • Scheduling: The scheduled events (which can be enabled on the POA) are automatic GWCheck jobs that are performed by the POA. The standalone GWCHECK.EXE does not provide tools for automation. As an administrator, you need not manually launch regular maintenance operations if you enable scheduled events.

The benefits of running POA-based GWCheck jobs far outweigh the fact that you cannot see the GWCheck log as it is being created, as the standalone GWCheck allows you to do. The standalone GWCheck is best saved for one-off operationsfor example, issuing a structural rebuild on a MSG XX.DB file.

If a post office is on the Linux platform, the standalone Linux GWCheck can be run right on the server that hosts the post office. So it does not need to run over the wire as the Windows GWCheck does against a NetWare server.

Benefits of Running GWCHECK.EXE

If there were no circumstances under which you might need the standalone GWCheck, Novell would not have written the tool. Here are a few cases in which GWCHECK.EXE is preferred over the POA's routines:

  • Low risk to the server: In cases where you suspect that a corrupt database is causing the POA to abend a NetWare server, you should try GWCHECK.EXE. If this routine dies while doing a database repair, it will not take the whole server with it. Fortunately, these cases are getting fewer and farther between.

  • Ability to watch it work: Some administrators like to see what GWCheck is doing. The POA does not log GWCheck operations onscreen, but GWCHECK.EXE does. When troubleshooting is being done, or a one-user GWCheck is being done, this is fine. For regular maintenance routines, though, the server-based GWCheck routine is always better.

There are many times when the standalone GWCheck is helpful; however, if it's a decision of whether to use the standalone GWCheck versus the POA-based GWCheck, use the server-based GWCheck if possible.

Getting GWCheck Log Files

It is always a good idea to review GWCheck logs, even if you don't want to watch the operation work. To receive a GWCheck log from the POA, make sure that you are set up as the administrator of the domain that owns the post office against which you are running GWCheck. The steps to do this are listed here:

1. | Highlight the domain object, right-click, and select Properties.
2. | From the Identification property page, click the button to the right of the Administrator field.
3. | Browse to your eDirectory user object and click OK.

Tip

The eDirectory user object you select must be grafted to a GroupWise mailbox. Also, the visibility of this mailbox should be set to system.

The next time the POA runs a GWCheck operation, the log file will be emailed to the user defined as the Administrator of the domain that owns this post office.

Tip

If you are not able to change the defined administrator of the domain that owns the user you want to run GWCheck on, you can click the Results tab before running the GWCheck operation, and then specify that the log file (or the results) be sent to your GroupWise mailbox. This way, you never have to change the domain administrator, but you can still get the GWCheck log files. You can also send the results to the user if you want. Most of the time, the user has no idea what he or she just received, so we rarely use this option unless we are running a mailbox statistics type of GWCheck and we want the user to see these types of results.

Understanding Scheduled Events for Post Office Maintenance

Every POA object has a Scheduled Events property page. This page is used to create, schedule, and edit events for the POA.

Every scheduled event has two parts: the event and the associated action or actions. The event is the record that tells the POA what triggers to use. The actions are the operations that the POA will perform when the triggers have been set.

Triggers can include low disk space (for the disk check event type) or a particular day of the week and time of day (for the mailbox/library maintenance event type). Actions can include analyze/fix mailboxes or expire/reduce.

Events and actions created from one POA are visible by (and can be executed by) every other POA on the system.

Tip

Even though events and actions can be used by multiple post offices, we suggest making events and actions specific to each post office in your system. We've seen problems occur when an administrator of one post office modifies a scheduled event that has an action that is catastrophic for another post office.

Managing Scheduled Event Creation and Modification

It should be obvious (especially to administrators of large systems) that you will want to manage how administrators create and modify scheduled events.

The following are considerations you should take into account when creating scheduled events:

  • Rights: For a GroupWise administrator to create or modify a scheduled event, or any of the listed actions, he or she must have supervisory rights to the primary domain object in eDirectory. If you need to control access to scheduled events, restrict administrators' access to the primary domain object.

  • Administrative procedures: Although an administrator might be restricted from creating or modifying events or actions, even with object rights restricted, you will want to ensure that the right operations run on the right information stores. There are two ways to do this:

    • Create different scheduled events for each post office: Naming conventions are critical here. In this case, we recommend that administrators name their events using the name of the post office the event applies to.

    • Create standard events that work for all post offices: Again, naming conventions are important. Make sure that the name of the event describes the operation.

In the next section you are encouraged to create scheduled maintenance routines one post office at a time, naming the events appropriately.


Creating Scheduled Events for Maintenance

Here is the sample scenario used in this section:

WorldWide Widgets wants to implement scheduled events for information-store maintenance. The company has established an email retention policy stating that all GroupWise messages will be retained for only 90 days, excluding calendar appointments. Furthermore, all trash items will be deleted every morning. Those users who use GroupWise remote, or use the GroupWise client in caching mode, can retain items for as long as they would like. Archiving is encouraged if users want to retain messages beyond 90 days.

This section assumes the task of creating scheduled events for CORPPO.

Structural Maintenance

This example begins with the structural maintenance. This event will analyze and fix the structure of all information-store databases on a daily basis.

The following are the steps for creating a scheduled event to keep a post office's message store structurally consistent:

1.
Edit the POA for CORPPO.

2.
Go to the Scheduled Events property page, shown in Figure 17.1.

Figure 17.1. The Scheduled Events page for the CORPPO POA

[View full size image]

3.
Click Create and enter CORPPO-Structure-Event as the name of the event.

4.
Change the Type field to Mailbox/Library Maintenance.

5.
Change the Trigger field to Daily and the Time field to 1:00 AM. If you have problems changing the Trigger field, see the Tip.

Tip

If the Trigger field does not change to show you the time intervals as shown in Figure 17.2, click the OK button, and then come back into the Scheduled Events page. The Trigger field will then show the time intervals.

Figure 17.2. Defining the scheduled event

[View full size image]

You now have the event name, type, time, and trigger. What hasn't been set up yet is what the event will do. You now need an action. Your scheduled event should look something like what's shown in Figure 17.2.

6.
Click Create.

7.
Enter CORPPO-Structure-Action (the name of the action helps you associate it with the appropriate event).

8.
Select the Action named Analyze/Fix Databases.

9.
Put check marks in the Structure, Fix Problems, User, and Message check boxes.

Figure 17.3 shows a configured action.

Figure 17.3. Defining the scheduled event action

Tip

In our own testing we have found the "Index Check" of a user database to be a good thing, but potentially very time consuming. Only use the "Index check" option if you have plenty of time for this GWCheck routine to run.

10.
Click the Results tab at the bottom of the window and make sure that the results are sent to the administrator.

11.
Click OK once to store the action, and then make sure that a check mark is placed next to the action. Click the OK button again, and you now have the structure scheduled event defined.

That's the first event; now you have more to create. The structural maintenance of your post office is the most important, so it should be run regularly.

Contents Maintenance

Now you need to make sure that the content of the CORPPO information store is checked regularly.

The following are the steps for creating a scheduled event to keep a post office's message store's pointers from record to record consistent:

1.
Edit the POA for CORPPO.

2.
Go to the Scheduled Events property page.

3.
Click Create and enter CORPPO-Contents-Event as the name of the event.

4.
Change the Type field to Mailbox/Library Maintenance.

5.
Change the Trigger field to Weekday, and change the day to Sunday and the time to 12:00 PM, as shown in Figure 17.4.

Figure 17.4. Defining the event

[View full size image]

Note

You will always see the other actions created though the system; however, do not place a check mark next to these actions. These actions are specific to other scheduled events in the system.

6.
Click Create to create an action.

7.
Make the name CORPPO-Contents-Action.

8.
Select the Action named Analyze/Fix Databases.

9.
Select the Contents, Collect Statistics, Fix Problems, Update User Disk Space Totals, User, and Message check boxes.

10.
Click the Results tab, and make sure that the results are sent to the administrator.

11.
Click OK once to store the action, and then make sure that a check mark is placed next to the action. Click the OK button again, and you now have the contents scheduled event defined.

Note

You might notice, in step 9, that we checked several check boxes under the contents event action. A contents GWCheck job takes a long time as it is, so why not do everything in the same pass? It's just more efficient.

Trash Deletion

Now you need to indicate when to regularly delete the contents of the CORPPO information store.

The following are the steps for creating a scheduled event for trash deletion:

1.
Edit the POA for CORPPO.

2.
Go to the Scheduled Events property page.

3.
Click Create and enter CORPPO-Trash-Event as the name of the event.

4.
Change the Type field to Mailbox/Library Maintenance.

5.
Change the Trigger field to Daily and the time to 2:00 AM.

6.
Click Create.

7.
Make the name of your action CORPPO-Trash-Action.

8.
Select the Action named Expire/Reduce Messages.

9.
Select the Expire and Reduce radio button.

10.
Put check marks in the Trash Older Than, Received Items, Sent Items, and Calendar Items check boxes, and make sure that the Trash Older Than field is set to one day.

Tip

If you are using the smart purge features, you might want to check the Only Backed-Up Items option. If you are not using the smart purge features, do not check this box. If you do, and you have not fully implemented a backup solution that works with the NetWare TSAFS software, mail messages will not get purged, and your information store will continue to grow. On the Linux platform, use the GroupWise Time Stamp utility. It is located in the /opt/novell/groupwise/agents/bin directory. The name of the utility is gwtmstmp.

11.
Make sure that the Items Older Than, Downloaded Items Older Than, Items Larger Than, and Reduce Mailbox To check boxes are not checked, as shown in Figure 17.5.

Figure 17.5. Deleting trash items with a scheduled event

Tip

The Downloaded Items Older Than option is referencing messages that have been downloaded by GroupWise remote or the GroupWise client running in caching mode.

12.
Click OK once to store the action, and then make sure that a check mark is placed next to the action. Click the OK button again, and you now have the trash deletion scheduled event defined.

Now you need to create a fourth and final eventthe one that expires old mail:

1.
Edit the POA for CORPPO.

2.
Go to the Scheduled Events property page.

3.
Click Create and enter CORPPO-Expire-Event as the name of the event.

4.
Change the Type field to Mailbox/Library Maintenance.

5.
Change the Trigger field to Weekday. Change the day to Saturday and the time to 6:00 AM.

6.
Click Create to create the action to be taken.

7.
Make the name CORPPO-Expire-Action.

8.
Select the Action named Expire/Reduce Messages.

9.
Select the Expire and Reduce radio button.

10.
Select the following check boxes: Received Items, Sent Items, and Items Older Than (set this last one to 90 days).

11.
Make sure that the following check boxes are not checked: Downloaded Items Older Than, Items Larger Than, Trash Older Than, Reduce Mailbox To, Reduce Mailbox to Limited Size, Calendar Items, and Only Backed-Up Items.

Figure 17.6 shows the correct configuration.

Figure 17.6. Defining the expire scheduled event action

12.
Click OK once to store the action, and then make sure that a check mark is placed next to the action. Click the OK button again, and you now have the mail expiration scheduled event defined.

There you have it. You have now implemented a scheduled event for keeping the message store more manageable. We highly recommend an expiration event. With that and a third-party archiving solution such as "GWArchive" by www.messagingarchitects.com or Discovery by www.nexic.com, you can create a solution that keeps the GroupWise message store manageable, while giving your users access to messages they must retain.

Order and Timing of Scheduled Events

Before you run a content analysis of a database, you should make sure that the structure is okay. In the preceding walkthrough, the scheduled contents analysis occurs after the structural analysis. The expire event in the sample scenario was scheduled to come after the contents event.

In short, before you check contents,you should ensure that the structure is clean. Before you expire anything,you should ensure that the contents are consistent.

Seeing a POA's Scheduled Events from the Console Screen

You can see which scheduled events a POA intends to carry out by doing the following:

1. | Go to the POA screen.
2. | Press the F10 key, and select Configuration Options, Show Configuration. This dumps the POA's current configuration to the POA's log file.
3. | Press the F9 key and view the end of the log file. You will see the configuration information for the POA, including the scheduled events you have created. If you do not find these scheduled events, you need to rebuild that post office's WPHOST.DB file. Tip You can also view the scheduled events by accessing the HTTP port of the POA and clicking the Settings page.

Editing Scheduled Events

Take care when modifying scheduled events. Sometimes modifications do not correctly propagate down to the post office. You can check this by looking at the POA log to see which events are enabled. If the events don't match changes you made in ConsoleOne, you either need to rebuild the post office database or delete and re-create the events in question.

Because of this possibility for problems, we typically recommend that if you need to edit a scheduled event, don't. Instead, delete the action for the event and then delete the event itself. Then you can re-create the scheduled event and the action associated with it.


GroupWise Archive Message Store Maintenance

Most users have no idea that the GroupWise client has GWCheck built into it. If a user is complaining of problems in an archive mailbox that seems like database damage, you can have the user run GWCheck on his own archive. Here's how to do it:

1. | Have the user open the archive mailbox.
2. | Have the user select Tools, Repair Mailbox


GroupWise Windows Client Caching Mode and Remote Mode Maintenance

The GroupWise client can be installed with a GWCheck version that will run against a caching/remote mode mailbox. This GWCheck is installed and enabled only if the administrator indicated that it should be. The GWCheck code can be installed and enabled via SETUP.CFG when the GroupWise client is installed. This can be done by adding the following three lines in SETUP.CFG:

[GWCHECK]
InstallGWCheck=Yes
GWCheckEnabled=Yes

To learn more about configuring the SETUP.CFG file for the GroupWise installation, see Chapter 12, "Administering the GroupWise Client." If GWCheck is installed and enabled, your users can run GWCheck on their caching/remote mailbox by choosing Tools, Repair Mailbox. A scaled-down interface of GWCheck will launch, as shown in Figure 17.7.

Figure 17.7. GroupWise Caching/Remote Mode GWCheck screen

Unfortunately, there's not an easy way to kick off a scheduled maintenance on users' caching and remote mode mailboxes. The users must do this themselves.

Troubleshooting Server-Based GWCheck Problems

Sometimes you'll issue a GWCheck job to execute on the POA, and the job won't seem to happen, you won't get a log, and so on. We've seen this problem before, and it's related to some corruption in the GWCheck databases at the post office. Here are the steps you take to resolve this issue:

1. | Bring down the POA.
2. | Go to the post office directory (where the WPHOST.DB file is).
3. | Rename the NGWCHECK.DB to NGWCHECK.OLD.
4. | Go to the post office\WPCSOUT directory, and delete the subdirectory structure called CHK.
5. | Restart the POA.

This method deletes all the old GWCheck data components at the post office and gives the post office a fresh start. The POA will re-create these components when it reloads.

Non-GWCHECK/GroupWise Message Store Maintenance

There are two other maintenance settings on the POA that must be enabled to keep the message store in good shape. These maintenance settings are not GWCheck routines available to you from the GWCheck or Mailbox/Library Maintenance interfaces. Here they are:

  • Perform User Upkeep: This setting is available from the Maintenance property page of the POA. Make sure that this setting is enabled. The best time to have Perform User Upkeep execute is in the early-morning hours, for example 1 a.m. Performing user upkeep, among other things, advances tasks in users' mailboxes and calendars. It also deletes trash items that might be set to expire according to the Client Options cleanup settings for the mailbox.

  • QuickFinder Indexing: This setting is enabled from the QuickFinder property page of the POA. Make sure that this setting is enabled. The best time to have QuickFinder Indexing run is during off-peak hours. Our experience has shown that if you keep QuickFinder Indexing turned off, performance on your POA will slowly deteriorate. The reason for this is that the POA must create real-time indexes anytime someone uses the search feature or a query folder in the GroupWise client. Without QuickFinder Indexing enabled, rather than the POA going to a pregenerated index, the POA must build an index on-the-fly, which can greatly impact the performance of the POA.


GroupWise Directory Database Maintenance

GroupWise uses two repositories for directory information: Novell Directory Services (eDirectory) and the GroupWise FLAIM or GDS databases (as discussed in Chapter 3, "Understanding the GroupWise Directory").

Maintenance of Novell Directory Services (eDirectory) is beyond the scope of this book. Suffice it to say that if eDirectory is messed up, it can cause problems for GroupWise. This section focuses on maintaining the WPDOMAIN.DB and WPHOST.DB files.

Our experience is that these files do not get corrupt nearly as often as information-store databases. This is probably because they are not being written to as often as the information-store databases. Thus, it is not as critical that you run regular rebuilds of domain or post office databases.

The most important thing is that your WPDOMAIN.DB filesfor all domainsare backed up regularly. Ideally, you should have this file backed up every day. Don't bother backing up the post office databases (WPHOST.DB), however. These files can be regenerated from the WPDOMAIN.DB file of the domain that owns the post office.

The single most important file in a GroupWise system is the primary domain's WPDOMAIN.DB file. We recommend that you run a recover-and-index rebuild of the primary domain monthly. This cannot be automated. Fortunately, you don't have to bring anything down in order to do this.

Here are the steps for a monthly maintenance of the primary domain's WPDOMAIN.DB:

1. | Connect to the primary domain by choosing Tools, GroupWise System Operations, Select Domain. Select the domain database for the primary domain.
2. | Highlight the primary domain and choose Tools, GroupWise Utilities, System Maintenance.
3. | Select the action called Recover Database.
4. | After the recover action is done, do a Rebuild Indexes for Listing action, which is also accessed from Tools, GroupWise Utilities, System Maintenance.

These operations are simple and take very little time to perform. Consider creating a monthly task item to remind you to perform these operations on the primary domain's WPDOMAIN.DB.


Summary

With the help of scheduled events, maintaining the GroupWise information store is easy. This chapter has shown you the events you need to schedule to ensure that your GroupWise information store stays healthy.

GroupWise directory database maintenance must be done manually. Fortunately, the GroupWise directory databases are far less susceptible to damage, so they do not need to be checked as frequently as the information store.


Chapter 18. Monitoring Your GroupWise System Through GroupWise Monitor

All GroupWise 7 agents and gateways have an HTTP-monitoring functionality. GroupWise Monitor takes your system beyond HTTP monitoring. Although HTTP monitoring of agents and gateways is a powerful tool, and some features are available only through HTTP monitoring, there is no alert mechanism. With GroupWise Monitor, you can be alerted to problems without having to stare at a computer screen, waiting to see whether a problem is happening.


The GroupWise Monitor Components

The GroupWise Monitor software has two separate components. They are the GroupWise Monitor Agent and the GroupWise Monitor Application. Here are some details about both of these components.

GroupWise Monitor Agent:

  • Runs on the Windows or Linux platform.

  • Provides most of the features of GroupWise Monitor Application, except it does not support HDML (handheld device markup language for wireless telephones, typically) and simple HTML support.

GroupWise Monitor Application:

  • Runs on any web server that supports the GroupWise WebAccess Application (the Monitor Application is normally installed on the same server as the WebAccess Application).

  • Works only in conjunction with the GroupWise Monitor Agent.

  • Provides HDML and simple HTML template support for the GroupWise Monitor Agent.

  • Can act as a proxy server to access the HTTP information from each GroupWise agent.

The GroupWise Monitor Application cannot exist without the GroupWise Monitor Agent. The GroupWise Monitor Agent has no dependencies on the GroupWise Monitor Application.


Installing GroupWise Monitor Agent

The GroupWise Monitor Agent can be installed on a Windows NTclass operating system (2000, XP, and so on) or on a Linux server. This chapter will guide you through the installation of the GroupWise Monitor Agent on Windows. Following that, we will demonstrate installing the GroupWise Monitor Application on the Linux platform.

The GroupWise Monitor Agent can be installed on a Windows NTclass operating system (2000, XP, and so on). We recommend installing GroupWise Monitor on an auxiliary Windows 2000 workstation or server computer that you intend to always keep running. By doing this, the GroupWise Monitor can monitor your system continually. This section assumes that you are installing GroupWise Monitor on a Windows NT/2000 computer.

Preparing Your Windows Environment by Installing Windows SNMP Services

Before even trying to install the GroupWise Monitor Agent, you should install the SNMP services for Windows. The following are steps needed to install SNMP services on a Windows 2000 workstation machine:

1. | Go to the Control Panel.
2. | Select Add/Remove Programs.
3. | Select Add/Remove Windows Components.
4. | Choose the Management and Monitoring Tools option.
5. | Click Next to allow Windows to install the SNMP.

To confirm that the SNMP service is installed and running, do the following:

1. | Go to the Control Panel.
2. | Select Administrative Tools.
3. | Select Services.
4. | Look for SNMP Service.

With SNMP services enabled, you can now proceed to the GroupWise Monitor installation.

Installing GroupWise Monitor Agent on Windows

The GroupWise monitor installation utility is located in your GroupWise 7 SDD\ADMIN\MONITOR directory.

Following are the steps for installing the GroupWise Monitor Agent:

1.
Run the SETUP.EXE program in this directory.

2.
Proceed to the GroupWise Monitor: Components screen, shown in Figure 18.1.

Figure 18.1. Choosing which GroupWise Monitor components to install

3.
Select the GroupWise Monitor Agent.

Later in this chapter, you will install the GroupWise Monitor Application. It's generally easier to implement the agent first, and then implement the GroupWise Monitor Application as needed.

Note

The GroupWise Monitor Agent is sufficient for monitoring your GroupWise system. The GroupWise Monitor Application allows an administrator to see the information on the GroupWise Monitor Agent from additional interfaces such as HDML and simple HTML. It also allows the administrator to drill down into each GroupWise agent's HTTP port from a single entry point.

4.
Specify the correct IP address and port for the GroupWise Monitor utility, as shown in Figure 18.2, and then click Next.

Figure 18.2. Entering the GroupWise Monitor Agent information

Note

The GroupWise Monitor Agent can itself be accessed from a Web browser. That's the purpose of the Port field.

5.
GroupWise Monitor can monitor both your GroupWise mail environment and your GroupWise Messenger environment, as shown in Figure 18.3. GroupWise Messenger is described in Chapter 29, "Configuring a GroupWise Messenger (Instant Messaging) System." Select at least the GroupWise option and click Next.

Figure 18.3. Selecting the GroupWise components to be monitored

6.
Specify the path to a WPDOMAIN.DB in your system, from which the GroupWise Monitor Agent can read the configuration information about agents in your system, and then click Next.

7.
Select the language you would like for GroupWise Monitor, and click Next.

8.
View the summary and make sure that everything is correct, and then click Next. If it is not correct, you can use the Back button to correct things.

The GroupWise Monitor Agent is now installed; you should further tune the Monitor Agent, as explained in the next section.


Configuring Your System to Better Support GroupWise Monitor

The GroupWise Monitor Agent cannot be configured from ConsoleOne. However, the information that GroupWise Monitor uses to monitor your GroupWise system is spread all throughout your system. To make all the features of GroupWise Monitor work, you must enable three components:

  • HTTP monitoring of GroupWise agents

  • SNMP monitoring of GroupWise agents

  • Message logging on GroupWise message transfer agents (MTAs)

Enabling HTTP Monitoring

The chapters in this book regarding the GroupWise post office agent (POA), MTA, GroupWise Internet Agent (GWIA), and WebAccess components all tell how to enable HTTP monitoring. To review, see each of those chapters. But in short, here's how you enable HTTP monitoring on all GroupWise agents.

Following are the steps for enabling HTTP monitoring of GroupWise agents:

1. | Start ConsoleOne.
2. | Go to the Properties of the agent (MTA, POA, WebAccess, or GWIA) you want to enable HTTP monitoring on, and go to the Network Address option under the GroupWise tab.
3. | Enter the HTTP port value.

Note

Make sure that the HTTP port value is in fact the HTTP port on which your agent is listening. If you are using the /HTTP* switches in the startup files of your agents, you might not be using the same values as are specified in ConsoleOne. If a GroupWise agent has /HTTP* switches in its startup file, those switches take precedence over the HTTP values in ConsoleOne. The GWIA keeps the /HTTP* switches in its GWIA.CFG file; that's where they should be for the GWIA. For all other agents, though, it is not recommended that you use the /HTTP* startup switches in your agent's startup files, because managing them is more difficult than doing the job through ConsoleOne.

After you have completed adding HTTP monitoring support, you will need to restart the GroupWise agents for which you enabled HTTP monitoring.

Enabling SNMP Monitoring

All the GroupWise agents can be monitored via SNMPin fact, SNMP monitoring is a default on all GroupWise agents. The GroupWise POA can be configured to disable SNMP monitoring, though, so here's how to enable SNMP monitoring on the GroupWise POA.

Follow these steps to enable SNMP support for a GroupWise POA:

1.
Run ConsoleOne.

2.
Go to the Properties of the POA object.

3.
Go to the Agent Settings property page.

4.
Slide down to the bottom of the Agent Settings property page and check the Enable SNMP check box, as shown in Figure 18.4.

Figure 18.4. Enable SNMP by checking the Enable SNMP check box and entering the GET string

[View full size image]

5.
Enter the word public (case-sensitive) in the SNMP Community "Get" String field below the Enable SNMP check box.

Note

A discussion of SNMP community get strings is outside the scope of this book. You are welcome to change the SNMP Community "Get" String field according to your organization's SNMP guidelines.

Enabling MTA Message Logging

To enable MTA message logging, follow these steps:

1. | Run ConsoleOne.
2. | Edit the properties of the MTA object.
3. | Go to the Message Log Settings property page.
4. | Change the Message Logging Level field so that it says Full.
5. | Don't fill in the Message Log File Path field unless you want to change the message logging path. By default, the MTA will place the message log files in the DOMAIN\MSLOCAL\MSGLOG directory.
6. | Check all check boxes except Track Administrative Messages. Rarely will you need to track ADMIN-type messages through the system.
7. | Set a value, such as 30 days, for the Delete Report After field.

Figure 18.5 shows MTA message logging enabled.

Figure 18.5. Enabling MTA message logging is accomplished from the Message Log Settings property page

[View full size image]

Now the MTA is logging information that is very useful when tracking message flow. These logs are separate from the typical MTA logs.


Starting and Using the GroupWise Monitor Agent

You've now installed the GroupWise Monitor Agent on either Windows or Linux and configured your environment. Now let's see how to load the GroupWise Monitor Agent.

Starting the GroupWise Monitor Agent on Windows

On Windows the GroupWise Monitor Agent is installed to the Start, Programs menu tree of the Windows computer where GroupWise Monitor Agent was installed. By default, GroupWise Monitor is installed in a folder under Start, Programs, Novell GroupWise Monitor.

Note

The GroupWise Monitor Agent does not run as a Windows service. Thus, if the Windows machine that is running the GroupWise Monitor Agent is restarted, the GroupWise Monitor Agent will not run until someone logs in to the Windows machine.

Using the GroupWise Monitor Agent

After starting the GroupWise Monitor Agent, you get a list of the agents that the GroupWise Monitor Agent was able to discover from your GroupWise system. This list is generated when the Monitor Agent reads the WPDOMAIN.DB file for information about the system. By default, all agents will be placed in a folder in the left pane that is your GroupWise system name.

GroupWise Monitor is a very powerful and configurable tool. It's kind of like a piece of soft clay. You can mold GroupWise Monitor into many tools. Thus, this chapter gives an explanation of some of the menu selections in GroupWise Monitor. There are no "best practices" for configuring GroupWise Monitor, so this chapter doesn't tell you how to configure GroupWise Monitor, or which fields to enable. Instead, it just explains the functional purposes of many of the features in the GroupWise Monitor. It is best to explore GroupWise Monitor and construct your own monitoring solution with GroupWise Monitor.

The whole idea of GroupWise Monitor is to allow you to view the state of your GroupWise system and notify you of problems or potential problems. The GroupWise Monitor Agent introduces the concept of grouping your various agents together in whatever type of groups you want. This gives the administrator the capability to logically or physically organize all the GroupWise agents in the system in whatever manner makes sense for your particular GroupWise system. For example, you can create a folder for each site of your company. You can then create subfolders to organize your agents. To create folders, right-click any parent folder and choose Create. You can then create a group or a folder to drag agents into. Figure 18.6 shows you the WorldWide Widgets Monitor and illustrates how various folders have been created to organize the agents.

Figure 18.6. The GroupWise Monitor Agent displays the status of all GroupWise Agents

[View full size image]

Tip

When you drag and drop agents into various folders, they are moved into the destination folder. However, you can have parent folders display the agents contained in child folders by right-clicking the parent folder and selecting Show Subgroup Agents. This places a small black down arrow on the folder to signify that this folder is set to view its subfolders' agents.

When you load the GroupWise Monitor Agent, the agent will read the monitor.xml file to determine where the WPDOMAIN.DB file is. It will then connect into the WPDOMAIN.DB file to identify which agents you have in your GroupWise system. Next, it will attempt to open an HTTP connection to each agent. If your agents are password protected on their HTTP port, you might get a pop-up prompt for each agent in order to enter the agent's HTTP user and password settings. If you see this, it is because the agent's HTTP user and password settings are not stored in the WPDOMAIN.DB file and are most likely set up in the agent's startup file. Because of this, it is much easier to define the HTTP user and password on your various GroupWise agents through ConsoleOne so that this information is in the WPDOMAIN.DB file, and the Monitor Agent can read this to authenticate to the agent. You can attempt to work around the pop-ups by using some startup switches on the Monitor Agent that feed the HTTP user and password settings into the various GroupWise agents for monitoring them.

The /httpuser- and /httppassword- switches are placed on the command line where you load the Monitor Agent. Here's an example of how this might look on Windows:

C:\gwmon\gwmon.exe /lang-us /httpuser-webmon /httppassword-letmein

The GroupWise Monitor Agent supports several other switches that may be of interest to you. To discover these switches, run the GroupWise Monitor Agent with the /? switch (on the Windows platform). For example:

C:\gwmon\gwmon.exe /?

The next sections talk about how to enable three kinds of notifications:

  • Visual notification

  • Audio notification

  • Remote notification

Configuring Visual Notification: GroupWise Monitor Agent Interface

The main GroupWise Monitor Agent screen, shown in Figure 18.6, gives you an eagle's-eye view of the state of your GroupWise system. The goal is to see green check marks next to each agent. If you see a red circle with an x through it, or a yellow circle with an exclamation mark in it, these are visual alerts that either an agent is down or GroupWise Monitor cannot get hold of an agent for some reason. When an agent in a particular folder has a visual alert on it, the alert icon is placed next to the folder. This allows you to quickly identify whether any agents in any folder are in an alerted state.

You can get more information about any one of your GroupWise agents by double-clicking the agent. A details screen comes up, as shown in Figure 18.7.

Figure 18.7. Agent Details shows why GroupWise Monitor flagged an agent as having problems

[View full size image]

You can get even more details by viewing the SNMP values that the agent makes available. To do this, click the MIB Values button. Figure 18.8 shows the MIB values that come up on a POA agent.

Figure 18.8. The SNMP/MIB values on a POA show which settings from a POA can be monitored with an SNMP request

[View full size image]

The SNMP/MIB values of an agent contain the information you can monitor. By default, the Monitor Agent will query the agents via the HTTP port of the agent. If this port is inaccessible, it will revert to using SNMP to poll the agent. The Poll Type is identified on the Agent Details dialog box, as illustrated in Figure 18.7. If it is XML, the Monitor Agent is using the HTTP port to poll the agent. If you see the Poll Type of SNMP, you know that the Monitor Agent is using the SNMP protocol to poll this particular agent.

Reports

With the Reports option, you can get real-time reports of configuration information, message flow, and so on. The reports features are pretty self-explanatory. What you should know, though, is that the user traffic, link traffic, and message tracking features all derive information from the message logs of the GroupWise MTAs in your system. These aren't the regular logs the MTA uses; these are the special logs that are enabled when MTA message logging is enabled. Enabling MTA message logging was explained earlier in this chapter.

Environment

The Environment report option will show you information about your entire GroupWise environment. It displays things like the agent name, the agent type, the agent version, the agent's IP address, the agent's port, and the server that the agent is running on. You can also opt to send this report to any email address. When you click the Send icon when viewing the Environment report, you can enter the From and To email address and the Monitor Agent will act like an SMTP server to send the message out.

User Traffic

The User Traffic report can track the messages sent by a particular user, within a time frame that you specify.

Link Traffic

The Link Traffic report tracks the number of messages sent between domains in your system.

Message Tracking

Message Tracking is a powerful but complex feature. As shown in Figure 18.9, this feature requires some investigation on your part.

Figure 18.9. The Message Tracking Report feature allows you to search for a particular message to determine when it passed through the MTA

[View full size image]

First here's a scenario in which you might use this feature:

  • USERA on PO1.DOM1 sends a message to USERB on PO2.DOM1.

  • USERB did not receive the message, and USERA shows the status of the message as pending.

You are the administrator; you want to know what happened to the message. Here is the information you would gather:

1.
Have USERA go to his Sent Items folder.

2.
Have USERA view the properties of the message sent to USERB.

3.
Have USERA tell you the value on the line that reads Mail Envelope Properties located at the top of the properties page.

The value you want is everything between the parentheses. For example, Figure 18.10 shows the properties of a mail message, when the Mail Envelope Properties are 41B62AE5.9EF : 12 : 6249.

Figure 18.10. The properties of a GroupWise message reveal the Message ID value

[View full size image]

4.
After you have the Mail Envelope Properties value, you have the Message ID value needed for the GroupWise Monitor message tracking report. Enter this same value in the Message ID field of the Message Tracking Report window, and select DOM1 as the starting domain.

5.
Click the Track button to generate the report.

This section explained how to track a message. For a message to be tracked, it must be sent to at least one recipient outside the post office.

Performance Testing

With the Performance Testing feature GroupWise Monitor can send a message at a regular interval, and at that moment test the speed of message delivery and processing. First you must configure Performance Testing under Configuration, Performance Testing. After you have configured Performance Testing, you can select Reports, Performance Testing and see a nicely configured report showing the performance trends.

Link Trace

Link Trace is a great tool that allows you to quickly and easily trace the link(s) from one MTA to another in your GroupWise system. Figure 18.11 displays the Link Trace tool with a link traced from the CORP domain to the MFG domain. You can see that the CORP domain is linked directly to the MFG domain, that the link is open, and that there are no queued messages waiting to be sent from CORP to MFG. In a large GroupWise system, this tool can be invaluable in identifying how the link configuration is defined on your system.

Figure 18.11. You can use Link Trace to trace MTA-to-MTA links

[View full size image]

You can also place a check mark in the Trace Return Path option to have the Link Trace tool trace the links in both directions. For example, it will check the link from CORP to MFG, and then back from MFG to CORP in one step. This is useful to identify whether the two domains are configured correctly from the perspective of each MTA. One thing to note is that if there are problems in your link configuration, this tool will detect them and will show a visual alert.

Link Configuration

The Link Configuration tool is used when you need to know how an MTA talks to all other domains in the system. You can also use it to run a report on every MTA in the system, and what this MTA's link configuration is. Once again, if there are problems such as link configuration loops in your system, this tool will identify them and alert you with a visual alert. Figure 18.12 shows the link configuration of the MFG domain. Notice that MFG's link to Ntdom is an indirect link through the CORP domain.

Figure 18.12. The Link Configuration tool can trace the speed of domain-to-domain links

[View full size image]

Configuring Visual Notification: GroupWise Monitor Agent HTTP Interface

The GroupWise Monitor interface allows you to define custom SNMP monitoring views of your GroupWise system. The GroupWise Monitor has a Web-browser interface, and you can use GroupWise Monitor, even when you are away from the machine running the GroupWise Monitor Agent.

To enable HTTP monitoring and to enable the HTTP interface to gain quick access to GroupWise agents, you need to define a user and password in order to access the HTTP port of the Monitor Agent. This allows you to check your GroupWise system by accessing the HTTP port of the agent directly. You can define the HTTP user and password on the agent by going to Configuration, HTTP and selecting the option to Require Authentication to Browse GW Monitor. Next, you define the user and password switches, and, if desired, you can define the intruder detection.

Specifying the HTTP Port for GroupWise Monitor Agent

The GroupWise Monitor Agent listens on a configurable port. You should check to see whether this port is enabled, and what it is enabled for. To do this, go to Configuration, HTTP in the GroupWise Monitor Agent Windows interface, as shown in Figure 18.13.

Figure 18.13. HTTP configuration for the GroupWise Monitor Agent can be configured using a number of settings

Make sure that the HTTP Port field is filled in, and make note of this port.

Accessing the HTTP Interface Through a Web Browser

Here is how you access the HTTP interface of the GroupWise Monitor Agent through your Web browser. Use the following line in your browser:

http://monitor computer's IP address or DNS name:monitor's HTTP port

For example:

http://137.65.32.63:8200

You should get an interface similar to the one shown in Figure 18.14.

Figure 18.14. The GroupWise Monitor Agent as it appears in a Web browser interface

[View full size image]

After you are in, you get an interface that is much like the Windows interface. There are a few distinct advantages to this interface:

  • HTTP access to GroupWise agents

  • Extra reports: Connected Users, Gateway Accounting, Trends, and Down Time

  • Custom views, including a view on the DVA, the WebAccess Document Viewer Agent (see Figure 18.15)

    Figure 18.15. GroupWise Monitor offers the Custom Views option

    [View full size image]

  • A Map view of your system

HTTP Access to GroupWise Agents

From the main status screen in the Web browser interface of GroupWise Monitor, you can click any of the agents in the Name column, and you are immediately transported to the HTTP port of that agent and the resulting HTTP interface of that agent.

Tip

You can configure GroupWise Monitor to open the HTTP screen of agents in a new browser window. This way, you always have GroupWise Monitor, and you can access the HTTP interfaces of your other GroupWise agents at the same time. To do this, go back into the GroupWise Monitor's Windows interface and choose Configuration, HTTP. In the HTTP Configuration window, check the Open a New Window When Viewing Agents option.

Custom Views

With custom views, you can define the SNMP traps that you want to monitor (see Figure 18.15).

Rather than explaining these traps (there are more than 200 of them), you can go to the status screen in the Web-browser interface and click an agent along the Status column. Here you will see each of the SNMP values filled in for that agent. With a little bit of thinking and matching, you should be able to determine the SNMP traps available to you. Now you can create an SNMP custom view:

1. | Go back to the Custom View screen.
2. | Select which type of agent you want to set up a custom view for (MTA, POA, GWIA, WebAccess, DVA, Gateway, NMMA, or NMAA (these last are Messenger Agents, as explained in Chapter 29).
3. | Select the SNMP traps you are interested in. (The traps you see here are specific to the type of agent you are defining the trap for.)
4. | Give the custom view a name by filling in the View Name field.
5. | Click the Add View button at the bottom of the page. You have just created your own custom view that you can click to see just what you have defined.

This section explained visual notification by the WebAccess Agent. The next section explains how to get audio notification from the WebAccess Agent.

Configuring Audio Notification

The GroupWise Monitor Agent can play sounds when certain events have happened. This is useful if the GroupWise Monitor Agent is in earshot of your desk. To enable audio notification, choose Configuration, Notification, and then check the Play Sound option. To define the sounds you will hear with various thresholds, click the Sounds button, and you will see the window shown in Figure 18.16.

Figure 18.16. GroupWise Monitor sounds can be customized according to the nature of the event that causes Monitor to make an audible notification

[View full size image]

You can browse to find sound files that will play on the events shown in the Sound Options window.

Configuring Remote Notification

This is a powerful notification method. With remote notification, you can have GroupWise Monitor send a message to the Internet email address for your pager, as well as to other email addresses. Here's how to do it:

1. | Go into the Windows interface of the GroupWise Monitor Agent.
2. | Choose Configuration, Notification.
3. | Select the Notification Events you want to be notified of.
4. | Enter the Notification list with email addresses to send notification to, separating each address with a comma.
5. | In the Mail Domain field, specify the mail domain name for your organization. Our organization is worldwidewidgets.com.
6. | For the Relay address, enter the IP address of a machine that will relay the notification onto the Internet for you. If you have enabled relaying on the GWIA, you can specify the IP address for your GWIA. However, you will most likely want to specify some other SMTP mailer in your system that you can relay off of in case the GWIA is down.

Tip

You can leave the Relay address blank and the Monitor Agent will send the email directly to the destination SMTP mail servers. This works because the Monitor Agent has its own built-in SMTP server that allows it to send mail directly. You'll normally use a relay server only if the box that is running the Monitor Agent is not able to do the DNS lookup.

Figure 18.17 shows the GroupWise Monitor configured for remote notification.

Figure 18.17. The Group Notification window shows that more than one email can be notified by GroupWise Monitor

Previous Page
Next Page


Installing the GroupWise Monitor Application

The primary reason you would want to install the GroupWise Monitor Application is if you want to be able to monitor your GroupWise agentsdown to the MTA, POA, GWIA, WebAccess, and Messenger Agent levelsecurely from outside your corporate network. This means that if you are out of the office, and you get notified that there are problems with the GroupWise system, you can access the Monitor Application from a Web browser and actually drill down into the POA's HTTP port to check into things. The second common reason to install the Monitor Application is to broaden browser integration for your GroupWise Monitor Agent. The GroupWise Monitor Application can integrate the GroupWise Monitor Agent's interface into your web server. A particular value to this is that you can leverage your web server's outside availability on the Internet to broaden your access to monitoring your GroupWise agents. As if that isn't enough, the GroupWise Monitor Application also supports monitoring via simple HTML devices, such as a Windows CE device, or HDML-wireless devices, such as a cell phone with a micro-browser.

Prerequisites to Installing the GroupWise Monitor Application

The GroupWise Monitor Application requires that you have a web server. The GroupWise Monitor Application was written to support one of five web servers:

  • Netscape Enterprise Server for NetWare

  • Apache Web Server for NetWare

  • Microsoft Internet Information Server (IIS) for Windows NT/2000 Server

  • Apache Web Server for Linux

  • Apache Web Server for UNIX Solaris

You must have the GroupWise agent installed before installing the GroupWise Monitor Application.

Installing the GroupWise Monitor Application for Linux

Don't bother installing the GroupWise Monitor Application unless you have a GroupWise Monitor Agent installed and running.

Following are the steps for installing the GroupWise Monitor Application on Linux:

1.
Run the install script from the GroupWise 7 for Linux CD or SDD.

2.
Proceed past the language dialog, and select Install Products, GroupWise Monitor.

3.
First you need to install the Monitor Application. If this server already has the GroupWise 7 WebAccess Application running on it, choose the option Install Monitor Application. If this server does not have GroupWise 7 WebAccess already installed, choose Install Monitor Application with Apache and Tomcat.

4.
After the simple install runs, choose the menu option Configure Monitor Application.

5.
Proceed past the license screen. On the first screen indicate the IP address and HTTP port of the WebAccess Agent, which in our example we installed on a Windows server. See Figure 18.18. Click Next to proceed.

Figure 18.18. GroupWise Monitor Application HTTP configuration information

[View full size image]

6.
On the Web Server Information screen take the defaults indicated, unless you happen to know that Apache and Tomcat are installed to a different path than what is indicated.

7.
On the LDAP Authentication page, you need to fill in the information for the installation to log in to eDirectory so that the WebAccess Application objects can be made in eDirectory. The notion of LDAP Authentication may be kind of new to you, so let us explain why you need to authenticate through LDAP. On the Linux platform there isn't really a NetWare client. As such, when the installation software wants to create an object in eDirectory, you must authenticate directly to eDirectory through the installation software. Doing so isn't particularly hard (generally); however, the syntax sometimes is difficult for people to grasp. Here is an example of how you would fill out the appropriate fields:

LDAP Server IP Address: A Server on your network that has eDirectory installed, and NLDAP loaded

Port: 389

Username in LDAP Format: Your fully distinguished name, with commas separating the eDirectory path rather than periods

Password: Your eDirectory password

See Figure 18.19 to see the authentication information.

Figure 18.19. LDAP eDirectory authentication information

[View full size image]

Tip

If you have authentication problems, check for the following: 1. Make sure that NLDAP is running on the server you are pointing to. 2. Make sure that the LDAP Group object associated with the server you are pointing to for authentication allows for clear-text passwords. In other words, make sure that it does not have the Require TLS for Simple Binds with Password option set.

8.
After proceeding to the Monitor Objects dialog, indicate a place in your eDirectory tree to put the two new GroupWise Monitor objects that will be created. You can use the Browse button now to browse your eDirectory tree. This way you can select an OU to place the new Monitor objects into. However, be aware that in some customer trees, when you try to browse, the install will just go away (it crashed). If this happens to you, just indicate the eDirectory path in the following manner, for example:

ou=ITS,ou=Provo,o=WWW

9.
Click the Next button. The Monitor object should get created in eDirectory, and the proper configuration file changes should be made to Apache and to Tomcat.

10.
Start the Apache web server and Tomcat, or restart them if they are already loaded. On our SLES9 server the commands to do this were as shown here:

Apache

/etc/opt/novell/httpd/init.d/httpd stop
/etc/opt/novell/httpd/init.d/httpd start

Tomcat

/var/opt/novell/tomcat4/bin/catalina.sh stop
/var/opt/novell/tomcat4/bin/catalina.sh start

11.
After the Monitor Application is installed, make sure that the Monitor Agent has authentication information that you need to get in order to have the Monitor Application talk to the Monitor Agent. Go to the Monitor Agent and select Configuration, HTTP. Be sure to fill in the username and password fields.

12.
If you need to make modifications to the configuration of the Monitor Application, you can do so by modifying the gwmonitor.cfg file. On our SLES9 server, this file was located in the following path:

/opt/novell/groupwise/gwmonitor

13.
To access the GroupWise Monitor Application, go to the following URL in a web browser:

http://your server's address/gwmon/gwmonitor

14.
Enter the HTTP username and password that you indicated in the GroupWise Monitor Agent's Configuration menu. Then click the Login button. After doing so, you should see the main GroupWise Monitor Application screen, as shown in Figure 18.20.

Figure 18.20. The GroupWise Monitor Application screen

[View full size image]

Note

The GroupWise Monitor Agent and Application are not in the GroupWise view in ConsoleOne, and they are not in the GroupWise WPDOMAIN.DB file. The GroupWise Monitor Agent is administered strictly from the agent itself. The GroupWise Monitor Application is administered from ConsoleOne in the NDS browser view.

15.
You get a summary screen at the end of the installation. If everything looks correct, proceed to install the GroupWise Monitor Application software.

The GroupWise Monitor Application is now installed. The GroupWise Monitor Agent must be installed and running in order for the application to function.

If you use a Pocket PC to access GroupWise Monitor, the interface might look like the one shown in Figure 18.21.

Figure 18.21. The GroupWise Monitor Application client interface as it appears in the simple HTML version

Note

The GroupWise Monitor Application also supports WAP devices, so you can access the Monitor Application from a phone as well.

The navigation buttons across the top of GroupWise Monitor HTML frames version allow you to switch to one of six views:

  • Problems: This shows you the agents that have problems. It does not matter whether the agent is in a particular group; it will display all agents in the system that have exceeded a threshold or are not reachable.

  • Link Trace: This is a way of checking the status of a link from one domain's MTA to another domain's MTA.

  • Link Configuration: This option allows you to check the link configuration of a particular MTA. It will check all outbound links from the selected MTA, and list how this MTA communicates to all domains in the system.

  • Global Operations: This option allows you to make basic configuration changes to the Monitor Agent from the Application Interface. You can change things such as the relay server, or the domain name, as well as when you send alerts.

  • States: This allows you to view all states the agents can be in. It also allows you to create custom states you can apply to various thresholds.

  • Search: This is a way of filtering for certain agents.

The online help in GroupWise Monitor is excellent and gives even more detail about how you might use these features.

Enabling Proxy Access to GroupWise Agents Through the Monitor Application

The Monitor Application and Monitor Agent can work together to allow you to access your GroupWise agent's HTTP interface through the application. You can access, say, a POA object's HTTP interface from outside your firewall with the Monitor Application acting as a proxy device. In other words, when you click a post office to drill down into its settings, the application will make the request to the agent on behalf of your browser, and will handle the information from the POA and send it down to your browser.

This functionality is not enabled by default. To enable it, perform the following steps:

1.
Edit the shortcut to the Monitor Agent and add the /proxy startup switch. For example, the following would start the monitor agent:

C:\gwmon\gwmon.exe /lang-us /proxy

2.
Shut down the Monitor Agent and then restart it.

3.
Locate the GWMONITOR.CFG file located in the on the web server that is running the GroupWise Monitor Application. Open this file with any text editor. On our SLES9 server, this file was located in the following path:

/opt/novell/groupwise/gwmonitor

4.
Look for the following section in this file:

#---------------------------------------------
# Specify the access level for the
web interface of GW agents. The options are:
# 1. none - NO access to agent's web interface
# 2. basic - Access to agent's
web interface from inside the firewall
# 3. full - Access to agent's
web interface from outside the firewall
#---Provider.GWMP.Agent.Http.level=basic

5.
Edit the Provider.GWMP.Agent.Http.level=basic field to equal full. It should read like this:

Provider.GWMP.Agent.Http.level=full

6.
Save the updated GWMONITOR.CFG file.

7.
Shut down and restart the Monitor Application servlet. On our SLES9 server the commands to do this were the following:/var/opt/novell/tomcat4/bin/catalina.sh stop

/var/opt/novell/tomcat4/bin/catalina.sh start

8.
Access the Monitor Application on your web server. Everything will look the same now, except that when you mouse over a hyperlink to an MTA, POA, GWIA, WebAccess, or Messenger agent, the URL will not send your browser directly to this agent. Instead, the URL will reflect the fact that the Monitor Application will get the details of the agent for you. With this you can drill right down into various agents from outside your firewall. A GroupWise administrator's dream, right?

Note

If you're using any template other than the standard Frames template, when you browse down into your various GroupWise agents, a new browser window will try to open in the standard agent view. This is because the GroupWise agent's HTTP interface has not been ported into the various templates. If you are accessing the Monitor Application via a cell phone using WAP, you cannot drill down into the various agents because of this incompatible format on the WAP device.


Summary

This chapter exposed the main functionality of GroupWise Monitor. GroupWise Monitor's strength is its capability to be customized and accessed from a broad variety of clients. Continue to explore GroupWise Monitor on your own, and see how you can customize it to your environment.


Part V: Applied Architecture

19 Building Your GroupWise System Correctly

20 Troubleshooting Message Flow

21 Moving Domains and Post Offices

22 Troubleshooting the GroupWise Directory

23 Troubleshooting GroupWise

24 Using Wireless and Handheld Devices with GroupWise 7 WebAccess

25 Configuring a Spam/Junk Mail Control Solution

26 Configuring GroupWise Authentication via LDAP

27 Securing Your GroupWise System via SSL

28 Restoring Deleted Users

29 Configuring a GroupWise Messenger (Instant Messaging) System


Chapter 19. Building Your GroupWise System Correctly

Back in 1993, when GroupWise was still WordPerfect Office, WordPerfect realized that poor planning had caused some of the worst problems administrators experienced with the product. Administrators often began installing and configuring their system without knowing in advance what they wanted it to look like.

The problems caused by failing to design the system correctly only got worse as the GroupWise product matured. This chapter helps you apply such architectural information as you plan your GroupWise system. The goals of this chapter are to help your installation run smoothly, and help you build a system that meets your needs. Most of all, though, your system should run the way you expect it to without your having to spend a lot of time or money on technical support.


General System Configuration

There are several basic principles of GroupWise system design you should try to adhere to. If you cannot, you should at least understand why the principle is important so that you can knowledgeably work around the problems that your nonconformity introduces.

Email, Calendaring, and Document Management Are Mission-Critical

The first principle is a simple one. The system you are going to build (or you inherited) is going to be critical to the day-to-day work of your users. If GroupWise is down, your users will stop getting work done. If GroupWise performance is bad, your users will complain and will be less productive. If data is lost from the GroupWise system, that data will have to be re-created by users. These productivity hits will ultimately affect your bottom line. Your business will lose money when GroupWise is not running optimally.

The application of this principle is equally simple. If the system is mission-critical, if business cannot take place without it, you need to be prepared to spend money on the necessary infrastructure to support the system. This includes a solid LAN and/or WAN, a good Internet connection, and modern network file server hardware. That old NetWare 4.11 server running on the P100 box will run GroupWise, but not nearly as well as a NetWare 6.x server with a XEON or Pentium 4 processor.

Mesh Message Transfer on the LAN

Message transfer agents (MTAs) can communicate via TCP/IP as they transfer messages between post offices. If you have multiple GroupWise domains on your LAN, you should probably avoid a star or hub configuration for network links. Allow every domain on the LAN to connect directly to every other domain. This will prevent bottlenecks, accelerate message transfer, and reduce the amount of network traffic.

Match WAN Message Transfer to WAN Topology

If you have more than one facility, or your offices are connected via wide area network technology (T2 or slower links), make sure that your MTA links match your WAN topology. This means that GroupWise domains should exist at the borders between the LANs. Use indirect connections between domains on one LAN and domains on another, allowing only a single pair of domains to communicate across the WAN. This will reduce network traffic on the WAN and prevent certain kinds of MTA problems, including TCP timeout errors.

Treat the Internet as part of the WAN. After all, your users will be swapping email with Internet users with great frequency. You should dedicate a domain to this WAN link.

Applying System Configuration Principles in the Real World

This section looks at how the principles from the preceding sections can be put into practice by examining a hypothetical organization and designing a GroupWise system for that organization according to the outlined principles.

The Scenario

All-American Widgets has corporate offices in Newark, Detroit, and Salt Lake City. They have regional sales offices in Atlanta and San Francisco. They have more than 11,000 employees.

In Newark, there are 2,500 employees, most of whom are in the sales, marketing, and engineering departments. These users are all connected to a 100MB fiber network.

In Detroit, there are 7,200 employees, all of whom are in the manufacturing division. Only about 1,000 of these users (the management team and a few stray engineers) have computers, but there are another 500 kiosks that are used by the employees on the plant floor.

There are 1,400 employees in Salt Lake City, in the service and support division. All 1,400 of them have computers, and they have a LAN similar to the one in New Jersey.

Finally, there are 15 employees in Atlanta and another 20 in San Francisco. These salespeople all have mobile computers, and there's a solid network in their home office building. They do not, however, have a network administrator.

The Newark System

It should be pretty simple to arrive at a good design for the Newark portion of the system. All-American Widgets is not going to use caching mode on the GroupWise client in a broad manner. Newark has 2,500 users, so you should have five post offices, one for every 500 users. Each post office gets its own file server.

Newark will have three domains. One domain will own the five post offices. An auxiliary domain will own the GWIA and will handle communications with the other remote sites. The third domain will be an auxiliary domain for the WebAccess gateway and Web server. So Newark gets eight file servers, five post offices, three domains, a GWIA, and a WebAccess gateway.

The Detroit System

Detroit is a little more complex. Detroit has a much larger user base, but most of the users aren't regular computer users. The Detroit site creates three post offices and two domains. One domain will have all the post offices below it. Two post offices will be for the 1,000 management folk. The third post office will have 6,200 mailboxes on it. We are breaking a rule here, but for good reason. These folks won't be using their mailboxes much. There are only 500 kiosks from which they can connect; so performance won't be a problem, and there will not be that much mail for them.

To simplify things, all the kiosks run WebAccess. That way, users don't have to worry about logging in and out of Windows to ensure that GroupWise Registry settings are correct.

Detroit will need two domains. One domain will own three post offices. The second domain will be an auxiliary domain to house WebAccess. So Detroit gets five file servers; three post offices; two domains, one of which will house only the GroupWise WebAccess gateway; and the Web server.

The Salt Lake City System

Salt Lake City is going to look a lot like Newark, only smaller. The 1,400 users can be squeezed onto just two post offices in a single domain. Salt Lake City has its own Internet connection, and the repair technicians there will be sending a lot of Internet email to customers they are supporting. A separate domain will handle WAN message transfer and will host the GWIA. Another auxiliary domain and server will host WebAccess and the Web server.

From the discussion on Internet addressing in Chapter 16, "Internet Addressing," you can probably guess that All-American Widgets is going to use overrides here. The Salt Lake City users will get a different Internet domain name (probably user@support.allamericanwidgets.com) and will use the local GWIA as their default GWIA.

The Remote Sales Offices

There are a couple of good options for handling smaller offices. First, you can place a post office in each location but place the domain in the corporate office. This would give these users great client/server performance when they are in the office, but it would require that somebody at least know how to reboot the server and load the remote console software so that it can be maintained from the corporate office.

A second solution is to put the salespeople's mailboxes on post offices in Salt Lake City, Detroit, and/or Newark. These users would use the GroupWise client in caching mode all the time, which won't be an inconvenience, because caching mode is optimal for users who are also on the road. This second solution is more ideal.

System Administration

With corporate headquarters in Newark, it makes sense that system administration is done from there. On a system of this size, you probably want to have a primary domain that does not own post offices. This means adding another server, and another domain, to the Newark site. You do not necessarily have to dedicate a server just for the primary domain, but it does help that the primary domain functions primarily as the GroupWise Directory Services relay location. In a GroupWise system, all updates to the GroupWise directory must replicate through the primary domain. There is no way to offload or load-balance the primary domain's job. Because of this, it's best that the primary domain have no other functions, such as servicing a post office, or a gateway, or even links between domains. In this perfect-world scenario, the primary domain will have mesh links to all other Newark domains, and nothing else to do but replicate GroupWise Directory Services administrative messages. It will connect indirectly to domains in Detroit and Salt Lake City via the routing domain that owns the GWIA.

Now you see why it's best to plan ahead. When you create a GroupWise system, the first thing you do is create the primary domain. But you cannot know where the primary domain is going until after you have the rest of the system plotted out.

Planning Your GroupWise System

Now you know the principles involved and you've looked at how they applied to a fairly large (hypothetical) organization. You are ready to begin planning your system.

Here are the common steps to use when planning your GroupWise system:

1.
First, identify how many users you are going to be providing services for. Does everyone have a computer? Will everyone get an account, regardless of whether they have a computer?

2.
Divide your user base into groups, based on your network topology first, and then on their departmental or workgroup affiliations. If you have a department with users in two different remote sites, those users probably get grouped separately.

3.
Take these groups of users and divide them into post offices of between 400 and 2,000 users. If you plan to put anywhere between 1,000 and 2,000 users on a single post office, plan to spend top dollar on file server hardware, and be prepared for backups to take a while. Also, if you plan on putting more than 1,000 users on a post office, it is highly recommended that the users in this post office run in cache mode. This is a must in order to support this number of users in a single post office.

4.
You should now have a list of post offices, and a rough list of which users belong to them. You are ready to begin assigning domains. On LANs, one domain can serve at least 10 post offices. For systems of more than 2,500 users, though, I recommend at least three domains: one primary domain, one post office domain, and one gateway domain.

5.
Determine where your LANs interface with WANs. Plan for a routing domain at each of these locations.

6.
Begin drawing the links, and compare this to a map of your networks. Make sure that it makes sense. Remember, your network links should follow your WAN topology. If a packet moving from site A to site C must be transferred across a T1 line to site B, and then across a 56Kbps line to Site C, you will want to have three domains involved, one at each site.

7.
Plan your gateways and assign them to domains accordingly. The most important of these is the GWIA. Make sure that you know which domain it is going to belong to, and where it is going to reside. Know what the foreign ID is (your Internet domain name).

8.
The WebAccess application should be running on a server that is dedicated to just run the Web server and the WebAccess application. Multiple WebAccess agents should be running throughout your system. Those agents can be running on the same servers as the post offices. If WebAccess agents that are running in protected memory abend, no harm is done to the server.

9.
Now begin assigning names. Remember the discussion on naming conventions in Chapter 16. Post office and domain names should have numerical characters in them to unquestionably distinguish them from usernames. Try to keep names of domains and post offices short. This will make things simpler to manage.

10.
Draw the system, complete with names, links, and user groups. Sleep on it. Run it by your boss. If you are the boss, run it by your spouse, significant other, fishing buddies, evil minions, or trusted lieutenants. Invite commentary and criticism. Listen.

11.
Develop a standard for ports. This should include message transfer ports (MTP) for message transfer agents (MTAs) and post office agents (POAs), as well as client/server ports for POAs. Also include live remote ports for MTAs and plan for HTTP ports for all agents. An example of this is to have all client/server ports end in 7, such as 1667, 1677, 1687, and so on. If you ever have two post offices on the same server, you already know which client/server ports they will be using. HTTP ports could end in 1, for example, 1671 or 1681. An example of MTA MTP ports might be that they all end in 0, as in 7100, 7110, 7120, and so on. Make all POA MTP ports end in 1, as in 1661, 1671, 1681, and so on. It is nice to have a standard document in relation to all the GroupWise ports that are involved in a GroupWise system. Table 19.1 represents this type of portnumbering scheme.

Table 19.1. Sample Port Number Scheme for GroupWise Agents

AGENT

MTP PORT

HTTP PORT

C/S PORT

POP PORT

IMAP PORT

CAP PORT

WEBACCESS PORT

MTA LIVE REMOTE

MTA

7100, 7200

7101, 7201

7107, 7207

POA

1670, 1680

1671, 1681

1677, 1687

143

1026

WebAccess

7211, 7311

7205, 7305

GWIA

9850

110/995

143/993

Now that you have the basics of your GroupWise system design down, there are some other issues you must deal with, particularly issues that affect data management.

Chapter 25, "Configuring a Spam/Junk Mail Control System," discusses configuring GroupWise for Spam control. You must have a Spam solution in place.


Post Office Configuration

Most of what goes on in a GroupWise system also goes on at the post office. If you configure your GroupWise post offices correctly, your users will be far more satisfied with GroupWise.

Email Policies

Email policies might not seem technical, but they affect how you are going to configure elements of your post office. Your organization should have an email policy that establishes rules such as the following:

  • How long messages can be retained

  • Whether users have disk-space limits on their mailboxes

  • The size of attachments that users can send within your organization and on the Internet

  • Whether users can archive their mail messages

  • Whether users can use POP3, IMAP4, or NNTP

  • Whether users can share address books or folders with users outside their post office

  • Whether users can send messages via S/MIME or PGP

  • Whether there will be a standard disclaimer signature on all emails

By establishing an email policy, the GroupWise administrator can do the following:

  • Set GroupWise client options to mirror email policies

  • Do a better job of projecting the need for hardware resources

  • Design the GroupWise GWIA to disallow huge-bandwidth-consuming attachments going on the Internet

  • Set size restrictions on internal GroupWise links if needed

  • Run reports to see who is hogging disk space, and encourage the abusers to delete certain sent- or received-mail items

  • Automatically encourage users to curtail retaining too many messages

Tip

Even if your organization will allow users to retain messages for a long time, we strongly advise that your organization create a large-file-attachment policy. You can control attachment size, right down to the post office level. So, for example, you might decide that users cannot send files over 25MB. Furthermore, you could have a policy that requires that all files over 10MB be saved or deleted within seven days of receipt. To control attachment sizes, go into ConsoleOne, highlight a domain or post office, and choose Tools, GroupWise Utilities, Client Options, Send, Disk Space Mgmt. You can also control attachment size through Link Configuration. The difference in these two approaches is in how the user is notified of the problem. When you use the client option, users get a notice when they click Send that the attachment is too large. When you're using link configuration, the user can send the message, but as soon as the message hits an agent (POA or MTA) that has a link configuration size limit imposed, this agent sends back an undeliverable message to the sender, letting the sender know that the message could not be sent because of the size limit.

Email policies have an important effect on performance and server design. A great resource in constructing an official email policy is the "Email Policy Configuration & Deployment Guide." At the time this book was written, this guide was available at http://www.messagingarchitects.com/epolicy.

Post Office Design

This section offers a few tips to consider when designing post offices for your GroupWise system.

When and Where to Create a Post Office

Every GroupWise post office has a certain amount of cost associated with its maintenance. A GroupWise post office will generally reside on a server by itself; that server should have a high-quality disk subsystem and be made by a reputable hardware manufacturer. A backup solution should also be implemented for this server.

It is best to create GroupWise post offices only when it is really warranted. In the past, GroupWise administrators often had to make small post offices to service regional sites. With the advancements of the GroupWise WebAccess, and the GroupWise client in caching mode, it's feasible to move users from small regional post offices into centralized post offices.

Where to Place Post Offices in eDirectory

When a user logs into GroupWise and if the NetWare client is loaded, GroupWise will look in eDirectory to discover information about the user's post office and POA. Because of this, it is best to put the GroupWise post office object in proximity to the users associated with the post office. If the users associated with a post office are in multiple eDirectory contexts, place their post office in an eDirectory Organizational Unit (OU) that is in the same replica as the majority of the users on the post office. Users should have eDirectory browse, read, and compare rights to the post office object, as well as the POA associated with the post office.

Note

If you have LDAP authentication enabled, the Novell client is not used to query eDirectory, so these rules no longer apply. LDAP authentication effectively gives you more flexibility in designing the placement of your GroupWise post office objects in the eDirectory tree.

How Many Users to Place in a Post Office

If you have a good server and a fast network, GroupWise can scale nicely. The online client/server mode of the GroupWise client can be taxing on the server when a post office has several power GroupWise users. A GroupWise post office can easily sustain thousands of mailboxes; it's the number of users logged in at the same time that scale back the practical numbers of users on a post office. Take a close look at whether it is feasible to move to a distributed processing model; by using the GroupWise client in caching mode, the GroupWise client is far less chatty and taxing on the GroupWise POA. The downside to caching mode is that users need enough disk space to accommodate a complete copy of the items in their master mailboxes on the server. Also, caching mode is less attractive in environments where users don't have their own workstation, so-called "roaming users" in environments with flexible work spaces, because a copy of the mailbox will be stored on the local hard drive.

You need to consider other factors when determining the number of users per server. For example, does your organization have an email retention/expiration policy? If not, the message store is bound to grow and grow. Your servers might not have enough disk space to accommodate a message store for 1,000 users that just keeps growing. GroupWise is very efficient on disk space, but let's face it, email is the layman's FTP utility. When considering post offices, think about the people who will be on the post office and what their job functions are. Marketing departments are likely to have lots of presentation files. Engineering might have CAD files. Therefore, you might want to put only 250 of these kinds of employees on a post office. Production people might not deal with attachments at all, so perhaps you could put 750 of them on a single post office.

Multiple Post Offices on a Server

This is a subject that somehow stirs strong emotions among GroupWise specialists. GroupWise is flexible enough to allow more than one GroupWise post office to reside on a server. Many customers have experienced plenty of success with more than one post office on a server. Others have not had success using this model. Success or failure often comes down to usage patterns. If you have two 700-user post offices full of power GroupWise users on one server in client/server mode, you might have performance problems. When two GroupWise POAs are loaded on a server, they are not aware of each other, and they have a tendency to hog the CPU if they feel they must do so. The result is that, at certain times, one of the POAs will not have the CPU time that it might need to adequately service users.

The GroupWise product suite is getting even more robust, with features such as document management and increased third-party integration. Because of this, users are more and more likely to be using GroupWise. This is goodproductivity is going up. Just make sure that having two post offices on a server is not degrading the potential for good productivity. In general, based on the factors discussed previously, we do not recommend having more than one Post Office on a single server.

Configuring the POA Object for Optimum Performance and Functionality

This section discusses some settings and their relationship to a successful POA configuration. If a setting has no bearing on regular performance or function in the GroupWise system, it is not mentioned.

Agent Settings Property Page

The Agents Settings property page is shown in Figure 19.1. The Agent Settings property page is where you fine-tune the POA.

Figure 19.1. The POA Agent Settings property page allows you to fine-tune the POA

[View full size image]

Following are the parameters on the Agent Settings property page:

  • Message File Processing: This should be set to All. In some cases, a GroupWise POA will be created for QuickFinder indexing. That POA would have message file processing set to Off. Don't set this to Low or High; if you do so, the POA will stop processing items in some of its queues.

  • Message Handler Threads: Message handler threads should be set to about half the value of the TCP handler threads. If you have 16 TCP handler threads, the message handler threads should be set to 8.

  • Enable TCP/IP (for Client/Server): Yep, you want this enabled for sure.

  • TCP Handler Threads: This is a simple formula, as follows:

    A = Number of users

    B = The number of TCP handler threads that the POA should have allocated. The minimum value for B, though, should not go below six.

    B = A/25

    So if a post office has 400 users, the POA should be configured with 16 TCP handler threads. If a post office has 50 users, the post office should have six threads, not two. The POA should not be configured with fewer than six TCP handler threads.

    If your post office supports a significant number of users of a WAN link, even in Caching mode, you might want to monitor your TCP handler threads. You might need to increase the TCP handler threads to accommodate TCP connections that persist for a longer period.

  • Max Physical Connections: Allocate two physical connections for each member of the post office. This is generally plenty. Setting this value to four per user is not going to cause any problems either. Just don't set it to some astronomical number, which chews up more memory than necessary.

  • Max App Connections: Allocate at least four application connections for each member of the post office. More is fine, but much more is not necessary. This is one of those situations in which not enough is bad, more than enough is fine, and much more than enough is not needed or helpful.

  • Enable Caching: Caching mode can significantly improve POA performance. This setting allows the POA to cache various databases in server memory. The NGWGUARD.DB file is almost always a database that gets cached. The only time you should disable caching here is if your server is very unstable.

    Don't confuse this setting with the GroupWise client in Cache mode. This setting has nothing to do with whether users can use the client in cache mode.

  • CPU Utilization: We personally like to set this to 90% to 95%. If the server crosses the CPU utilization threshold, it will not allocate more threads until the POA is below the threshold. If your POA is on a NetWare server, 95% is generally fine. The beauty of NetWare is that it uses the CPU very efficiently and can regularly spike in the 90s without users feeling any effect. Because GroupWise is mission-critical, it should get priority processinggreater than the default 85%. Having the value at 85% will probably be fine also, but it likely should be the bottom threshold. We don't generally recommend going below 85%.

  • Delay Time: The delay time correlates with the CPU utilization option. If the CPU utilization threshold has been exceeded, the delay time is the amount of the time the POA's NLM will wait before trying to get another thread, if needed. The default of 100 milliseconds is generally more than enough.

  • Max Thread Usage for Priming and Moves: The default of 20 is pretty low. We personally like to set this to 50%.

  • Enable IMAP: Your Outlook and other IMAP client users can have a client/server-based connection with a GroupWise POA. We would recommend that if you allow your MS Outlook on users' desktops, you have a good virus-protection solution in place. A post officebased virus-scanning solution such as GWAVA (www.gwava.com) is a cost-effective solution to combat Microsoft Outlookbased viruses.

  • Max IMAP Threads: The default is set at 50. That might seem high, and it is if you just have a few IMAP users. But if you have several users, 50 or more will be necessary. IMAP connections have more overhead because they are standards based, rather than proprietary. So the POA must accommodate inefficiencies in the IMAP protocol.

  • Enable SOAP: Enable SOAP only if you have a third-party application that requires this protocol. Indicate the least number of default SOAP threads you may need, because SOAP threads can be resource intensive.

  • Enable SNMP: If you are not using SNMP monitoring, turn off this option. It saves a little overhead. The GroupWise monitor piece is an SNMP monitoring device, so if you intend to use GroupWise monitor, do not turn this off.

  • HTTP User Name and Password: You definitely want to set an HTTP username for your GroupWise POA's HTTP monitoring feature. There are powerful actions you can take from the POA's HTTP monitoring screen; you want to make sure that HTTP monitoring is secured.

Network Address Property Page

Not all of these settings necessarily affect the performance of the POA, but they do enable features that are important when monitoring your POA and extending its capabilities:

  • TCP/IP Address: The TCP/IP address can be an IP address or a DNS name. The advantage to a DNS name is that if at some time the IP address changes for a post office, the change simply needs to be made in the DNS. This change is transparent to the users.

  • Proxy Server Address: You can define a public IP address as the proxy IP address for the post office. This proxy server address is not bound to the server where the POA is; it is bound to a "proxy server" that's accessible from the Internet. The proxy server performs network address translation (NAT) services from the public IP address and port to the internal IP address and port of the POA. This enables your remote and cache users to connect to the POA using the full GroupWise client from anywhere they have an Internet connection. They do not need to VPN in to your network first.

  • Bind Exclusively to TCP/IP Address: Normally your POA will bind to all the IP numbers on your server and thus will offer its services on all of these IP addresses, even if you specified a (default) IP address in the field mentioned previously. In some cases, for example on clusters, this is not to be desired, and you might enable this option to make sure that the POA binds only to the IP number specified previously. This option was configurable only with earlier versions through the startup file.

  • Message Transfer Port: Domain MTA to post office POA communication can be configured in two manners: using UNC or via TCP/IP. The UNC method is one in which the MTA moves files to the WPCSOUT queues off of a post office. Also, in UNC mode, the MTA fetches messages from a post office using a polling cycle. The POA looks in the WPCSOUT queues periodically to determine whether anything needs to be processed. The polling process is far less efficient, because the MTA and the POA are not really talking to each other; they are just dropping things off in queues. Each agent knows that the other will look at the queues eventually.

    TCP/IP communication between the MTA and the POA is optimal. When a POA has something for the MTA, it hands it right to the MTA, and the MTA acts on the item immediately. It's the same when the MTA needs to give something to the POA. Quick handoffs are particularly helpful in time-sensitive functions. For example, when a user does a busy search on the calendar of a user on another post office, the busy search must pass from the POA to the MTA. Because the POA speaks directly to the MTA rather than placing the busy search request in a queue, the end user has a far more interactive experience with the busy search. Even if a domain and a post office are on the same server, it is still optimal to configure the post office and domain to communicate via TCP/IP.

    The message transfer port (MTP) is the IP port that the POA listens on for messages from the parent MTA of the post office. The MTP port should be different from the HTTP port and the client/server port.

  • HTTP Port: The HTTP port on the POA should be filled in. This enables the POA to be monitored from a Web browser. Some information is available from the HTTP monitoring of the POA that is not available from the POA's console screen, such as the names of users who are logged into the POA or the version of GroupWise client they are using. Even if you have the /HTTP switches in the startup file of the POA, you still should fill in the HTTP port here. The GroupWise Monitor program discovers the HTTP port of the POA from this field.

  • HTTP SSL: If you intend to monitor your POA via a Web browser across the Internet, you will want to use this option for security reasons. Enabling SSL is covered in Chapter 27, "Securing Your GroupWise System via SSL."

  • Local Intranet Client/Server Port: It's important that the POA is listening on a unique client/server port. The port used doesn't matter as long as it's unique. The default port is 1677.

  • Internet Proxy Client/Server Port: This port allows you to use the same proxy server address for all of your POAs in your GroupWise system. This is helpful because the proxy server address should be a public IP address. This Internet proxy client/server port can then be used to uniquely identify each post office in your system, which facilitates all user access to their post office through a single public IP address (the proxy server address). If your proxy server address is the same for all post offices, it is important that each POA have a unique Internet proxy client/server port defined.

    It is also important to note here that there is some additional configuration to make the proxy server address and Internet proxy client/server port to function. You must bind the proxy server address to a Layer 4 switch or some device that supports address translation (NAT), and possibly port address translation (PAT). This device must be accessible from the Internet. The device is then configured to translate the data that hits the proxy server address on a particular port (the Internet proxy client/server port) into the internal address and port of the correct POA.

  • IMAP Port: Most likely you will want to keep the default port (143). IMAP clients look for an IMAP server connection on port 143 by default.

  • SOAP Port: This port will be used by third-party solutions such as the Nexic Synchronis Palm and PocketPC client (www.nexic.com) and Teamware Mobile (www.teamware.com), as well as by the Evolution connector for GroupWise. Most of these services look for a SOAP connection on port 7191 by default.

After you have configured your POA's ports, be judicious about making any changes. The changes are likely to affect users who connect to this post office.

QuickFinder Property Page

Let's look at how QuickFinder Indexing can affect the performance of your POA:

  • Enabled QuickFinder Indexing: Make sure that this option is checked. QuickFinder indexing is critical to GroupWise performance. If you turn off this feature, your post office will slowly experience more and more utilization, because the POA will have to perform real-time QuickFinder indexing operations whenever users use the Find feature in GroupWise.

  • Start QuickFinder Indexing HoursMinutes: This value should be set to however many hours after midnight you want the QuickFinder indexing to occur. In most cases you want this process to happen after-hours, because it can be a CPU-intensive process. Setting the value to 22 hours and 0 minutes causes QuickFinder indexing to start at 10 p.m. each night. Setting the value to 0 hours and 30 minutes causes QuickFinder indexing to start at 12:30 in the morning (30 minutes after midnight). We recommend making sure that QuickFinder indexing does not happen during backups.

  • QuickFinder Interval: In most customer environments, the QuickFinder indexing should happen once every 24 hours and 0 minutes. We recommend you keep this default unless you have a legitimate reason to change it.

It's important that you have QuickFinder tuned, and always enabled.

Maintenance Property Page

Following is a discussion of the settings on the Maintenance Property Page:

  • Enable Automatic Database Recovery: If the POA discovers damage in a message-store database, having this option enabled allows the POA to kick off an immediate GWCHECK on the database.

  • Maintenance Handler Threads: The default is 4, and the most you can specify is 8. You can get yourself into real trouble if you set the maintenance handler threads to 8 and then issue a post officewide mailbox/library maintenance in the middle of the day. We did this once, and the maintenance handler threads were in a tug-of-war with the message handler threads to get access to the message store databases on the post office. So it's probably best to set this value to 4. If you then need more power for mailbox/library maintenance after-hours, crank this up to 8. You do not have to restart the POA when you change this setting; the POA will dynamically reread this setting. This gives you easy control over this feature.

  • Perform User Upkeep: This should definitely be enabled. The Perform User Upkeep option performs seven tasks:

    • Advances uncompleted tasks to the next day

    • Deletes expired items from users' mailboxes

    • Deletes mail, appointments, tasks, and notes that are older than what's defined in the "client options" section

    • Empties the trash based on client cleanup options

    • Synchronizes users' frequent-contacts books with the system's address book

    • Cleans address book indexes

    • Expires references from the document folder

Note

When the POA actually executes the Perform User Upkeep code, the upkeep happens in two passes. In the first pass, the POA advances uncompleted tasks and synchronizes users' frequent-contacts books with the system address book. In the second pass, the POA deletes expired items from users' mailboxes, cleans address book indexes, and expires invalid references from the document folder (if you are using GroupWise document management).

  • Start User Upkeep: Start User Upkeep should always be set to sometime after midnight to be effective. The Start User Upkeep option determines when the user-upkeep tasks occur. If you enable user upkeep to occur before midnight, it will not advance task items to the next day. If task items aren't advanced to the next day, the client's load-up time takes longer when the users log in the next day. As mentioned earlier, make sure that User Upkeep does not run during your backup cycle, but rather either before or after the backup.

  • Generate Address Book for Remote: You should definitely enable this setting. A better description for this is "Generate Address Book for Caching and Remote." If you have caching or remote mode users, you definitely want to enable this setting. This process creates a file called WPROF50.DB in the post office\WPCSOUT\OFS directory. This file is then used when users request the system address book while in caching or remote mode. If the WPROF50.DB file is more than 24 hours old (which happens only if you do not have this setting checked), the POA will create it again on-the-fly. Generating this file is a CPU-intensive task, so it is best to create the file after-hours.

  • Start Address Book Generation: Set this option to some time after business hours.

  • Disk Check Interval: Enable this to occur every five minutes.

    The Disk Check Interval value corresponds with any disk check event that you have defined in scheduled events on the POA. The POA looks at the scheduled disk check events. The POA takes the appropriate action specified in the disk check events, if the disk space threshold has been crossed.

  • Disk Check Delay: Leave this at two hours. If the POA has discovered that disk space is low, it won't take the actions in the disk check event until two hours have passed. This gives you a chance to respond to the low-disk-space problem.

It is imperative that you make sure that Perform User Upkeep is always enabled.

Log Settings Property Page

The settings available on the Log Settings property page include the following:

  • Log File Path: Just keep this value blank. The POA will create the files in the post office\WPCSOUT\OFS directory.

  • Logging Level: The Verbose setting is tremendously helpful when troubleshooting.

  • Max Log File Age: The default of seven days is generally sufficient.

  • Max Log Disk Space: The default of 65MB might not be enough. Crank this up as high as it will go if you have the space. This setting will go up to 1GB. You can then generally go back into the logs for several days to find information. The POA logs information such as what users deleted because of the junk-mail feature.

    Having this information for a few days is good. If someone mentions that he or she didn't get a message from someone on the Internet, you can search the logs of the POA and determine whether the message was junked by the recipient 's junk-mail rules.

Note

The Max Log File Age and the Max Log Disk Space settings work together. If your log files can grow to 50MB but you are storing only seven days' worth of logs, this means that even if your logs are taking up only 20MB, they will be deleted after the seven days. Conversely, if the log disk space is reached but logs are only five days old, the oldest log files will be deleted to make room for new log files. Also note that the Max Log Disk Space is cumulative of all the post office logs; it does not reflect how large one log file is. The POA cycles into the next POA log file when it reaches 1MB, or at midnight.

Log settings don't always have a direct impact on performance, but having correct log settings is very important for troubleshooting purposes.

Scheduled Events Property Page

Chapter 17, "Maintaining the GroupWise System," explains scheduled events and how to construct them. You definitely want to enable scheduled events for mailbox/library maintenance events. Chapter 17 does not discuss disk-space scheduled events though; that information is covered here instead.

If you left your Disk Check interval set at five minutes back on the Maintenance property page, a disk check event is spawned every five minutes. Also, the disk check event is defined on the Scheduled Events property page. Think this through for a moment. When do you want the red flag waved that disk space is low on a post office? We personally would like to be notified when 30% of our disk space is remaining. Here's what you do to create a notification mechanism that tells you when a volume that houses a GroupWise post office has dropped below 30%:

1.
Make sure that the POA has the Disk Check interval set at a reasonable disk check number, such as five minutes.

The Disk Check interval is a setting on the POA's Maintenance property page. Make sure that the Disk Check Delay setting is set at two hours, or some other value that you think is good enough. The Disk Check Delay option means that, when the POA has hit the trigger to start the action on the disk check event mentioned in the next step, it will wait another two hours before it kicks off the disk check event.

2.
Go to the POA's Scheduled Events property page and create a new scheduled event or edit the Default POA Disk Check Event option that ships with GroupWise.

3.
To edit the disk check event, make sure that the following settings are in place:

  • Type: Disk check.

  • Trigger: 30%; don't use the Stop Mail Processing At option.

4.
To create an action for the scheduled event, do the following:

  1. Click the Create button.

  2. Give the action a name in the Name field.

  3. In the Action drop-down box, select Expire/Reduce Messages.

  4. Enable the Reduce Only check box, as well as the User and Message check boxes under the Databases tab.

  5. Click the Results tab, and make sure that the results are sent to the administrator. You can also CC yourself if you are not defined at the administrator for the domain that owns this post office.

  6. Click the Message button on the Results tab and compose a message that says something like The post office has dropped below 30% in disk space; you will receive a message every two hours until this problem is resolved.

5.
Make sure that someone is defined as an administrator for the domain that owns the post office for which you are activating this disk check event.

This person will get the message regarding low disk space. It's generally best to make the administrator a dummy user with rules that forward messages to several people in your IS department.

Now you have a low-tech mechanism for determining whether the volume that houses GroupWise is running low on disk space.

Configuring the Post Office Object for Optimum Performance and Functionality

This section discusses some settings and their relationship to a successful post office configuration. If a setting has no bearing on performance or function in the GroupWise system, it is not mentioned.

Post Office Settings Property Page

Figure 19.2 shows the Post Office Settings property page.

Figure 19.2. The Post Office Settings property page

[View full size image]

Following are settings you can configure on the Post Office Settings property page:

  • Software Distribution Directory: Chapter 12, "Administering the GroupWise Client," discussed the Software Distribution Directory. The value you fill in here is important, but see Chapter 12 for a full explanation of the Software Distribution Directory.

  • Access Mode: This should be set to Client/Server Only. Don't allow users to connect directly to the post office via a UNC connection, because this will open the message store to a much higher likelihood of corruption.

  • Disable Live Move: Don't check this option unless you have good reason to do so. Live move is used when moving users. Live move is explained in more detail in Chapter 13, "Moving Users."

Client Access Settings Property Page

There is one simple setting that most customers will want to enable: Enable Intruder Detection. You can enable this setting anytime, and the POA will dynamically pick up the changes and apply them. You do not need to shut down the POA and restart it.

Security Property Page

This section offers a brief discussion of the most critical element of the Security property page.

For the Security level option, you want it set to High, with either the LDAP or the eDirectory Authentication option checked. If you have users who do not have the Novell client installed, make sure that the users have a password on a GroupWise account or you'll need to enable LDAP authentication. The whole idea is that if the security level is high, GroupWise needs users to authenticate through a password-authentication process. The authentication will be either before the GroupWise client is started, which is the case with eDirectory authentication, or at the time GroupWise is loaded, which is the case with LDAP authentication or a GroupWise password.

With LDAP authentication enabled, if a user does not have the Novell client, or a user is using GroupWise WebAccess through a Web browser, the user can still use an eDirectory password. The POA will query eDirectory via LDAP on behalf of the user. Your implementation of eDirectory must be version 8.5 or better, with LDAP services enabled and configured. Chapter 26, "Configuring GroupWise Authentication via LDAP," discusses enabling LDAP authentication, the best authentication solution.

Default WebAccess Property Page

The idea of a default WebAccess is important to the performance of WebAccess. But it's way too much to explain in this chapter; read Chapter 11, "Installing and Configuring GroupWise WebAccess," for more information.

Configuring the GroupWise Client Options for Optimum Performance and Functionality

The GroupWise client comes with a bunch of settings. Your organization might want to control some of these settings so that your email system is accomplishing its purposes.

GroupWise allows you to set client preferences and control features available to GroupWise clients. These preferences can be set at a domain level and excluded right down to a user level. There are a few features that, if used incorrectly, can generate more traffic in your system than you might want. Here are three client preferences to pay particular attention to:

  • Wildcard addressing

  • Status tracking

  • Junk-mail handling

The client preferences can be modified in ConsoleOne by selecting a domain, post office, or user object and choosing Tools, GroupWise Utilities, Client Options.

Following is a discussion of the client preferences that affect performance:

  • Wildcard addressing: Wildcard addressing is a great feature. With wildcard addressing, a user can send a message to all the recipients in a post office (that's the default), a domain, or even the GroupWise system and beyond that. The question then is whether you really want your users to have that kind of power. You can turn off all users' capability to use wildcard addressing at the post office level. Then for those users who should be allowed this functionality, you can enable it individually. You can configure wildcard addressing in ConsoleOne under Tools, GroupWise Utilities, Client Options, Send.

  • Status Tracking: GroupWise has a great feature called status tracking. You can determine whether a message got to its recipient, and you can see when the recipient opened the message. Status tracking sets GroupWise apart from other groupware packages. Status tracking can be taken to the extreme, though. If your GroupWise system's client options for status tracking is set to track all information, you will be generating a tremendous amount of data that does not need to be tracked. By requiring the GroupWise system to track all information, you impact the following:

    • GroupWise caching and remote users' downloads and uploads take longer.

    • When a user purges a large number of messages from the trash, a tremendous amount of disk I/O is created.

    • Status messages are generated for just about every action to a message item, and rarely do people need that information.

    • Most customers will not want to enable all information. Check to see that this is not enabled somehow. Many customers will want to lock this feature down so that end users cannot change the option to track all information.

Tip

It's helpful to simply browse through the client options and think about what settings you might want to configure or even which features you might want to turn off.

Now that we've told you all the evils of using too much status tracking, let's consider a different perspective. If your post office is using caching mode, it can be very helpful from a troubleshooting standpoint for you to set the status tracking to all, and then lock it. This will force this option to take effect on all user's mailboxes and caching mailboxes. For troubleshooting purposes, the status tracking can be invaluable. With the All Information option enabled, you can see when a user's caching or remote mode client actually downloaded the message.

Tuning a NetWare Server for Optimum Performance and Functionality

This section focuses on fine-tuning your NetWare server for optimum performance. These are the settings available:

  • GroupWise Only Volume: When you place a GroupWise post office on a file server, it is best to create a volume that will only house the GroupWise post office. This just makes managing email simpler; for example, you'll have a good picture of just how much disk space is being taken on a post office.

  • Compression: Do not enable compression on the NetWare volume dedicated for GroupWise. GroupWise already compresses the message store, and does so even better than NetWare does. It's redundant effort on the part of the NetWare operating system to try to compress files in the GroupWise message store.

  • Immediate Purge: GroupWise deals with a whole lot of files passing through queues off of the WPCSOUT and WPCSIN directories. Set these directories so that they are purged immediately. This allows the NetWare server to free up memory resources to optimize other parts of the NetWare server.

  • Server Set Parameters: The syntax on these settings has been confirmed for NetWare 4.x through NetWare 6.0. The values here are the minimum; if you currently have your NetWare server tuned to use higher or faster values, you don't need to decrease the values.

    The STARTUP.NCF file should have the following set parameters in it:

    Set TCP defend land attack = off

Set minimum packet receive buffers = 2000

    The AUTOEXEC.NCF file should have the following set parameters included in it:

    Set read ahead LRU sitting time threshold = 60
Set maximum file locks = 20000
Set minimum service processes = 100
Set maximum service processes = 1000
Set new service process wait time = 0.3
Set maximum packet receive buffers = 5000
Set new packet receive buffer wait time = 0.1

These set parameters will ensure that your server is more responsive than it would be otherwise.

Tuning a SUSE Linux Server for Optimum Performance and Functionality

This section focuses on fine-tuning your SUSE-based server for optimum performance. These are the settings available:

  • GroupWise Only Partition: When you place a GroupWise post office on a file server, it is best to create a partition that will only house the GroupWise post office. This just makes managing email simpler; for example, you'll have a good picture of just how much disk space is being taken on a post office.

  • File System Type: Use a Journaled file-system type. We suggest making the file system Reiser. And in the Reiser file system, disable Access Time logging. In YAST2 the check box on an OES server says No Access-time.


Best Practices

What we really want to do here is encourage you to design your system on paper rather than in stone. After you have created domains and named them, you cannot go back without starting over. When users have mailboxes in one place, it is extremely tedious to move them to another place. It is especially annoying when you have to do this because your boss does not like the name of the post office, but more often than not I see this being done because post offices were too large to begin with.


Summary

Post office design is the biggest contributor to the success of your GroupWise system. There are many aspects to good post office design, namely the following:

  • Email policies

  • POA configuration

  • Post office configuration

  • GroupWise client option configuration

  • Server configuration


Chapter 20. Troubleshooting Message Flow

This chapter explores GroupWise message flow in great detail. You get to look at the processes and store files involved in message creation, as well as the replication and transfer of messages between post offices.

The goal of this chapter is to enable you to troubleshoot GroupWise message flow through an understanding of the complete signal path for GroupWise messages.


Understanding Message Flow at the Database Level

To begin with, here is a look at the store files. When a user creates a message, one or more GroupWise information store files are written to. The particulars depend on the type of message. This section explores message flow using a few scenarios.

Each of the scenarios in this chapter follows the actions of UserA. UserA's GroupWise file ID (FID) is 123. Based on this FID, USERA is assigned to place all sent items in MSG17.DB.

GroupWise Information Store Concepts

Before proceeding, let's review some of the information store concepts. Most of this information is explained in Chapter 4, "Understanding the GroupWise Information Store," but for clarity's sake, this chapter reviews it.

GroupWise information (messages, address book info, rules, folders, and so on) is contained in the information store, which is composed of individual databases (also called store files). GroupWise information store databases are contained in each post office's OFUSER and OFMSG directories.

Databases are composed of records. Every record has a particular set of fields based on the record type. Some GroupWise fields can exceed 2KB. Fields that do exceed 2KB are called external BLOB (binary large object) files. BLOB files are contained in the post office\OFFILES\x directories.

Every item in GroupWisewhether it is a mail message, a task, a document, or anything else that can be displayed in a user's mailboxis just a record in a GroupWise information store database. Whenever a field within a record exceeds 2KB, that field is spun off to its own BLOB file outside of the database.

The User Database: USER xxx.DB

You might recall from Chapter 4 that every user has a user database. This file is named USER xxx.DB, where the xxx is replaced with the user's three-character file ID.

The easiest way to explain the user database file is that it is largely a pointer database. When USERA gets a message from USERB, the message isn't actually contained in USER123.DB. The message is contained in one of the message databases. A pointer to that message is created in the USER123.DB file.

The user database does contain records that represent complete items, however. For example, a user's folders and a user's personal calendar items are wholly contained in the USER xxx.DB file. Everything you see from the GroupWise client is coming from the user database. You will never look at anything that is exclusively stored in the message database from the GroupWise client. Most of the items you see from the client are simply pointers to the full message in the message databases.

The Message Database: MSG nnn.DB

Every GroupWise 7 post office can contain up to 255 message databases. Before GroupWise 7 there were only 25 message databases. All messages sent between users in a GroupWise post office are contained in one of the MSG nnn.DB files.

Group Items Versus Personal Items

When a user receives an email message or an appointment, a task, or a note, that item is considered to be a group item. Group Items are stored in the message database and linked to the user database, with possible overflow to the OFFILES. When a user creates an item in the calendar without sending it (that is, the item has no TO line), this is a personal item, also known as a posted item. Posted items are (only) stored in the user database, with possible overflow to the OFFILES.

Message "Body" Parts

A GroupWise item is not just one record in a database. There are distinct body parts on a GroupWise message, and every body part has its own record.

Every GroupWise mail message has a handful of body parts and records. The master record and the message properties record are always present on group items (items that one user sends to another user).

The following explains the different types of body parts in a typical GroupWise message:

  • Master record: The master record contains fields such as TO, CC, BC, and Subject. The master record also keeps track of all the other records associated with the original message. If the TO, CC, and BC lines contain more than 2,048 bytes of data, the master record relies on the message properties record to hold the entire contents of the TO, CC, BC, and Subject lines.

  • Message properties record: The message properties record shows the properties page of a message. If the contents of this record exceed 2KB (this happens often when sending to distribution lists), only the header of this record is kept in the MSG n.DB file. The remainder is spun off into a BLOB file in the OFFILES directory. Because the message properties record must contain the recipient list of the TO, CC, and BC lines, it becomes the master list for the TO, CC, and BC lines.

  • Message body record: This record contains the text and attributes of the GroupWise message's message area. If the message text is more than 2,048 bytes in length, this record will be spun off into a BLOB file in the OFFILES directory.

  • Attachment record: Each attachment has its own record. The attachment file is a field in the attachment record. If the attachment exceeds the 2,048-byte limit of the attachment field, it is spun off into the OFFILES directory.

Scenario #1: USERA Creates a Personal (Posted) Calendar Item

In this scenario, USERA creates a posted calendar appointment. The subject of the appointment is simply "Test". There is not a message body, or any attachments. Here are some observations:

  1. GroupWise puts the master record for the appointment in the USER123.DB file.

  2. GroupWise creates a message body record for the body of the appointment. This also goes in USER123.DB.

  3. A separate alarm record is written to the USER123.DB file. GroupWise Notify reads this alarm record.

Note

If an attachment had been made to the appointment, an attachment record will be created.

Scenario #2: USERA Sends a Message to USERB on the Same PO as USERA

In this scenario, USERA creates a short message with no attachments and sends the message to USERB:

  1. USERA's FID is USER123.DB. USERA's message database for outgoing messages is MSG17.DB.

  2. GroupWise creates three records in MSG17.DB. In this example, the master record is record #12 in MSG17.DB, the message properties record is record #11 in MSG17.DB, and the message body record is record #13.

  3. GroupWise creates a pointer in USER123.DB with a pointer to record #12 in MSG17.DB. GroupWise further indicates that this is a message sent by USERA.

  4. GroupWise creates a pointer in USERB's database. USERB's FID is 789, so USERB's user database is USER789.DB. The pointer indicates that this is an inbox item. The pointer also indicates that the record is record #12 in MSG17.DB.

  5. GroupWise successfully delivers the message to USERB, so GroupWise creates record #14 in MSG17.DB, which indicates that the message was delivered, and links record #14 to the master record, which is record #12. GroupWise also changes a value in USERA's user database to indicate that the delivery occurred and when it happened.

Here is a look at what happens when USERB opens the message from USERA:

  1. GroupWise creates a new record in MSG17.DB, indicating that USERB opened the message.

  2. GroupWise changes a value in the pointer record in USERA's user database, indicating that the item was opened and when it was opened.

Note

If a GroupWise message is sent to a user on a different post office, it takes a specific route through file queues on its way to the destination post office. Understanding message flow through a GroupWise system is one of the most valuable troubleshooting tools you'll ever have.

This scenario follows a message from one post office to another. The detail at the message store level is even more explicit than the detail previously described in this chapter.

Scenario #3: Message Flow Between Post Offices

In this scenario, the messages between the post offices flow as described here:

  • USERA is a user on PO1, which is a post office in DOMAIN1.

  • USERB is a user on PO2, which is a post office in DOMAIN1.

  • USERA's FID is 123.

  • USERB's FID is 789.

  • The MSG n.DB file for USERA is MSG17.DB.

  • All users connect to their post offices in client/server access mode.

  • PO1 is connected to DOMAIN1's message transfer agent (MTA) via MTP (TCP/IP) between the MTA and the post office agent (POA).

  • PO2 is connected to DOMAIN1 via a UNC link.

Note

We recommend that domain-to-PO connectivity be via TCP/IP; however, this scenario uses a UNC connection from a domain to a post office so that you can understand the message flow in case you are using a UNC connection.

The message store at PO1: USERA sends a message, with the subject "Test1". It contains a small message body and one attachment over 2KB. The byte size of the file is 93,812. The message is sent to USERB. Here's what happens:

  1. The POA on PO1 creates the following records in MSG17.DB:

    • A master record, which is record #385 in MSG17.DB.

    • The DRN (document record number), which is a unique identifier for the message 3827C415.FDE. The DRN for any GroupWise message can be viewed from the properties of a message. It will look much like this: Mail Envelope Properties (3827C415.FDE : 17 : 65002).

      Note

      The 3827C415.FDE is the DRN, the 17 is the message database that the users use, and 65002 is a number that uniquely identifies the user. Every sent message that this user sends will have 17:65002 in the Mail Envelope properties.

    • A message properties record, which is record #384 in MSG17.DB.

    • A message body record, which is record #382 in MSG17.DB.

    • An attachment record, which is record #383 in MSG17.DB.

    • A BLOB file called 382761a5.000 for the attachment that is created in the PO1\OFFILES\FD62 directory. The size of the BLOB file is 48,004 bytes. GroupWise compresses and encrypts BLOB files, which is why the file size decreased.

  2. The POA also creates a record in PO1\OFUSER\USER123.DB with a pointer to record #385. This user database pointer record contains the following additional information:

    • The DRN for record #385

    • The date and time that the message was sent

    • To whom the message was sent

    • Other status-tracking information as appropriate (delivered, opened, and so on)

  3. Now let's see what happens in the file queues at PO1. Because the message is destined for PO2, all records associated with the message having the DRN 3827C415.FDE are packed up into one file and placed in the PO1\WPCSIN\4 directory. The original name of the file is 482761a5.2l0. The file is 49,760 bytes. Because USERA sent the message with normal priority, it will travel through the 4 directory (where normal-priority mail messages always flow).

  4. The POA on PO1 transmits the file via TCP/IP to the MTA on its message transfer protocol (MTP) port.

  5. Now let's see what happens in the file queues at DOMAIN1. The MTA receives the message on port 7100 and writes the file into the DOMAIN1\MSLOCAL\GWINPROG\4 directory. As the file is being received, it's called XEF34B5F.000. When the file is completely received, the MTA renames the file to 00000859.5P5. The MTA uses what's called an MTP thread to receive the message.

  6. The MTA's MTP thread tickles the MTA's router thread (RTR) and notifies it about the message in the GWINPROG\4 directory. The router thread looks at the recipient post office for the message and determines that the recipient post office is PO2.

    Note

    The DOMAIN\MSLOCAL\GWINPROG\X directories are memory queues. This means that an MTA will fetch files from this directory only when it is prompted to by another subprocess of the MTA. These directories are scanned on startup or restart of the MTA, but that is the only time they get scanned. Sometimes, though, you might find files stuck in the GWINPROG\X directories. If this is the case, just put them back into the DOMAIN\WPCSIN\0 directory. If you find a file with an X at the beginning of the filename and it's been there for a long time, don't bother moving the file. It's a casualty of a bad transmission. Just delete the file.

  7. The MTA's RTR thread puts the file in the DOMAIN1\MSLOCAL\MSHOLD\PO25B46 directory, which is the FID for PO2.

    Note

    Every GroupWise object has an FID, be it a post office, a domain, or a user. To determine the FID for a post office, view the post office with GroupWise diagnostics and look for the attribute File ID.

    When in verbose mode, the GroupWise MTA will report the message DRN. In this case, the MTA reported the following:

    00:24:36 RTR: DOMAIN1: 00000859 Priority 4
3827C415.FDE:17:65002 : Transfer to DOMAIN1.PO2:OFS

  8. Now let's go to the file queues at PO2. The MTA's RTR thread copies the file to the PO2\WPCSOUT\OFS\4 directory. The name that it gives the file is 482769C4.2l0. The byte size of the file is 49,820. The size of the file increased a bit from when it was on PO1 because the route the message took to get to PO2 is appended to the message.

    Note

    The WPCSOUT\OFS directories are the input queues for the POA process. Every POA has an FID of OFS, so the input queue for the POA looks for work to do from the MTA in the WPCSOUT\POA'S-FID\X directory. The POA's FID is (or should always be) OFS. On rare occasions, the POA might have a different FID. If you discover this through GroupWise diagnostics, delete the POA and re-create it.

  9. Here's what happens at the message store at PO2. The POA picks up the file in the PO2\WPCSOUT\OFS\4 directory on its scan cycle and processes the file. The POA then commits the message to the message store at PO2.

  10. The PO2 POA creates the following records in MSG17.DB:

    • A master record, which is record #4 in MSG17.DB.

    • The DRN for this master record is 3827C415.FDE, just as it was on PO1. When viewing the properties of the message, USERB sees the same DRN as the sender. Mail Envelope Properties (3827C415.FDE : 17 : 65002)

    • A message properties record, which is record #3 in MSG17.DB.

    • A message body record, which is record #1 in MSG17.DB.

    • An attachment record, which is record #2 in MSG17.DB.

    • A BLOB file called 382774cd.000 for the attachment that is created in the PO2\OFFILES\FD62 directory. The size of the BLOB file is 48,004 bytesthe same size as the original file.

    • A status record, which is record #5 in MSG17.DB. The status record indicates that USERB received the message. This status record must be relayed back to PO1, which is coming up in a moment.

  11. The PO2 POA creates a record in PO1\OFUSER\USER789.DB with a pointer to record #4. The USER database also indicates the following:

    • The DRN for record #4

    • The date and time that the message was received

    • Who sent the message to USERB

  12. Here's what happens in the file queues at PO2. After the POA at PO2 delivers the message to USERB, it creates a status message to be sent back to PO1. The status message is placed in the PO2\WPCSIN\5 directory. The name of the file is 582774CD.2l0. The file is 820 bytes.

    Note

    The WPCSIN directory structure is the input queue for the MTA. The MTA for DOMAIN1 is configured to talk to PO2 via a UNC connection, so the MTA will pick this file up. This is different from an MTP connection in that the POA pushes information from the PO\WPCSIN\X directory up to the MTA. The POA push method through MTP is preferred, however, because it is more efficient.

  13. Here's what happens in the file queues at DOMAIN1. The MTA's RTR thread picks up the file from the PO2\WPCSIN\5 directory and places it in the DOMAIN\MSLOCAL\GWINPROG\5 directory. It then routes the file to the DOMAIN\MSLOCAL\MSHOLD\PO15B1E\5 directory. The name of the file is 0000085C.001, and it is 860 bytes.

  14. The MTA's router thread tickles the MTP thread and instructs the MTP thread to look in the MSLOCAL\MSHOLD\PO15B1E\5 directory for the file called 0000085C.001 to be processed.

    Note

    The MSLOCAL\MSHOLD queues are largely memory queues. This means that an MTA will fetch files from this directory only when it is given the file's specific name. The MSLOCAL\MSHOLD directories are scanned on startup or restart of the MTA.

  15. The MTA's MTP thread transmits the status file to the POA at PO1. The POA's MTP thread (listening on port 7101) receives the status file into its WPCSOUT\OFS\5 directory. The name of the file is 582782F4.210, and it is 860 bytes.

  16. The POA picks up the file and creates record #390 in MSG17.DB, linking that record to record #385, which is the original master record for this message.

Note

The last record used before the message was transmitted from PO1 to PO2 was #385. The reason the status record was #390 is that other records were written to the MSG17.DB file. GroupWise just picks the next available record number when writing a record into a message database.

Now you know what happens when messages are sent, which will help when troubleshooting message flow, or when trying to determine why you are seeing messages in a certain queue.

Important Architectural Concepts from Scenario #3

The preceding section tracked a message as it moved between two post offices on the same domain, exposing most of the architectural methods involved in message delivery:

  • Messages are either being submitted to a location or being sent out of a location.

  • If the message is being submitted to a location by the MTA, it is placed in a WPCSOUT\Process-File-ID directory. This is the MTA's output queue.

  • If the message is being sent out of a location, it is placed in the WPCSIN\X directory. This is the MTA's input queue.

  • Every message will pass through one of the eight queue directories, numbered 07. Here are the purposes of these queues (another review from Chapter 4):

    0:

    Live, interactive request messages (busy searches, remote library queries)

    1:

    Remote user update requests, shared folder, and shared address book replication messages

    2:

    Administration updates and high-priority messages

    3:

    Status messages from high-priority mail

    4:

    Normal-priority messages

    5:

    Status messages from normal-priority messages, mailbox/library maintenance requests

    6:

    Low-priority messages

    7:

    Status messages from low-priority messages

  • When messages reach an MTA, the MTA receives the file into the MSLOCAL\GWINPROG directories and then places the file into the MSLOCAL\MSHOLD\Location-File-ID directory. The file is then either transmitted (MTP via TCP/IP) or placed (UNC connectivity) at the destination. The file is then placed in the directory that corresponds to the FID of the process designed to process the message.

  • When a message is sent from one GroupWise post office to the next, the message will retain its DRN, no matter which post office it is sent to. If a message is sent to a gateway, the DRN is taken off by the gateway.

  • When a message is sent to more than one GroupWise post office, it is written to the same numbered message database on every post officethis is determined by the sender's FID.

  • Elements of a GroupWise message are broken into separate records. Fields of certain record types can exceed 2KB. If a field exceeds 2KB, it becomes its own BLOB file.

  • All elements of a GroupWise message are transmitted in one file when sent from one location to the next.

This section was heavily based on the GroupWise post office message store and flow within the message store.

Scenario #4: Message Flow Between Domains

In this scenario, User1 on PO1 at DOMAIN1 sends a message to User2 on PO2 at DOMAIN2. Here's the file flow. This scenario follows this message all the way to PO2 and then follows the status message back to PO1. This scenario does not focus as much on records and databases as the previous scenario did.

The next section focuses more heavily on message flow. The scenario is as follows:

  1. USER1 composes a low-priority message and sends it to USER2.

  2. The POA on PO1 creates a message transport file in the PO1\WPCSIN\6 directory.

  3. The POA at PO1 transmits the file from the PO1\WPCSIN\6 directory to the domain's MTA via TCP/IP, using port 7100.

  4. The DOMAIN1 MTA receives the file and, while receiving, places it in the DOMAIN1\MSLOCAL\GWINPROG\6 directory.

  5. After complete receipt, the DOMAIN1 MTA moves the file to the DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FileID\6 directory.

  6. The DOMAIN1 MTA transmits the file from the DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FileID\6 directory to DOMAIN2's MTA via TCP/IP, using port 7100.

  7. The DOMAIN2 MTA receives the file and, while receiving, places it in the DOMAIN2\MSLOCAL\GWINPROG\6 directory.

  8. After complete receipt, the DOMAIN2 MTA routes the file to the DOMAIN2\MSLOCAL\MSHOLD\PO2-FileID\6 directory.

  9. The MTP portion of the MTA picks up the file in the DOMAIN\MSLOCAL\MSHOLD\PO2-FileID\6 directory and transmits it via TCP/IP to the PO2 POA's MTP port 7101.

  10. The POA on PO2 receives the file and writes it directly into the PO2\WPCSOUT\OFS\6 directory.

  11. The POA processes the message and inserts it into the message store at PO2. The POA generates a status message and places it into the PO2\WPCSIN\7 directory.

  12. The POA transmits the file in the PO2\WPCSIN\7 directory up to the DOMAIN2 MTA at TCP/IP port 7100.

  13. The DOMAIN2 MTA receives the file into the DOMAIN2\MSLOCAL\GWINPROG\7 directory.

  14. The MTA moves the file to the DOMAIN2\MSOCAL\MSHOLD\DOMAIN1-FILEID\7 directory.

  15. The MTA transmits the file from the DOMAIN2\MSOCAL\MSHOLD\DOMAIN1-FILEID\7 directory to port 7100 on DOMAIN1's MTA.

  16. The DOMAIN1 MTA receives the file into its DOMAIN1\MSLOCAL\GWINPROG\7 directory.

  17. The DOMAIN1 MTA moves the file to the DOMAIN1\MSLOCAL\MSHOLD\PO1-FILEID\7 directory.

  18. The DOMAIN1 MTA transmits the file to port 7101 on the PO1 POA.

  19. The PO1 POA receives the file into the PO1\WPCSOUT\OFS\7 directory.

  20. The PO1 POA places the status record into the GroupWise message store on PO1.

As you can see, message flow is logical and predictable. Understanding message flow at this level is very helpful when troubleshooting GroupWise.

Scenario #5: Message Flow Through the GroupWise Internet Agent (GWIA)

In this scenario, USERA is on PO1 at DOMAIN1 and wants to send a message to joe@acme.com via the Internet. PO1 connects with DOMAIN1 via TCP/IP. DOMAIN1 connects with DOMAIN2 via UNC. The GWIA is located on DOMAIN2. Here is the file flow:

  1. The PO1 POA writes the appropriate item records to USERA's user database and assigned message database.

  2. Because the destination is not on PO1, the PO1 POA drops a transport file in the WPCSIN\4 directory.

  3. The PO1 POA transmits the file from the WPCSIN\4 directory at the post office to the DOMAIN1 MTA at the MTA's MTP port.

  4. The domain MTA receives the file and places it in the DOMAIN1\MSLOCAL\GWINPROG\4 directory.

  5. The domain MTA routes the file to the DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FileID directory.

    Note: You can determine a domain's file ID in a couple of ways. Perhaps the easiest way is by looking at the MTA's HTTP port and clicking Links. From there, you can click a particular link, and it will tell you what the hold queue directory is for the destination link. You can also go to the console for Domain1. Press F10, choose Configuration Status, highlight DOMAIN2, and press Enter. The Hold directory contains the domain file ID.

  6. Because DOMAIN1 has a UNC connection to DOMAIN2, it does not transmit the message to DOMAIN2 via TCP/IP. The DOMAIN1 MTA places the message in the DOMAIN2\WPCSIN\4 directory.

  7. The message is destined for the GWIA on DOMAIN2, so the file is moved to the DOMAIN2\MSLOCAL\MSHOLD\GWIA-FileID\4 directory by DOMAIN2's MTA.

  8. The MTA transmits the message to the GWIA via MTP on the GWIA's MTP port. The GWIA then places the message into the DOMAIN2\WPGATE\GWIA\WPCSOUT\GWIA-FileID\4 directory.

  9. The GWIA will convert the GroupWise message to ASCII and drop the converted file into the DOMAIN2\WPGATE\GWIA\SEND directory. This is the input queue for the GWIA's sending daemon.

  10. The GWIA generates a transferred status message to be sent back to USERA. The GWIA places the transferred status message in the DOMAIN2\WPGATE\GWIA\WPCSIN\5 directory. The GWIA then transmits the message to the MTA via TCP/IP on the MTA's MTP port.

    Also, after the GWIA's daemon transmits the message to the Internet recipient, it generates a conversation log about its transaction with the SMTP host on the Internet where the GWIA sent the message. That conversation log is kept in a file in the DOMAIN2\WPGATE\GWIA\SEND directory. The GWIA analyzes this file to see whether there is any reason to modify the status of the Internet message so that it says something beyond transferred.

  11. The DOMAIN2 MTA receives the status file from the GWIA into the DOMAIN2\MSLOCAL\GWINPROG\5 directory.

  12. The DOMAIN2 MTA tickles a RTR thread and notifies it about the file in the GWINPROG\5 directory. The RTR thread looks at the message and determines that the message is destined for DOMAIN1. The RTR thread places the message in the DOMAIN2\MSLOCAL\MSHOLD\DOMAIN1-FileID directory.

  13. The DOMAIN2 MTA's RTR thread tickles the MTP thread and notifies it about the file in the DOMAIN2\MSLOCAL\MSHOLD\DOMAIN1-FileID directory. The DOMAIN2 MTA transmits the file to the DOMAIN1 MTA on MTP port 7100.

  14. The DOMAIN1 MTA's MTP process receives the status message in its DOMAIN1\MSLOCAL\GWINPROG\5 directory.

  15. The DOMAIN1's MTA tickles a RTR thread and notifies it about the file in the DOMAIN1\MSLOCAL\GWINPROG\5 directory.

  16. The DOMAIN1 MTA's RTR thread routes the status message to the DOMAIN1\MSLOCAL\PO1-FileID directory.

  17. The DOMAIN1 MTA's RTR thread tickles the MTP thread and notifies it about the file in the DOMAIN1\MSLOCAL\PO1-FileID directory.

  18. The DOMAIN1 MTA's MTP thread transmits the status message to the PO1's POA on its MTP port.

  19. The POA at PO1 receives the status message in the PO1\WPCSOUT\OFS\5 directory.

  20. The POA at PO1 appends the status message to the message store at PO1.

This section was unique in that it showed message flow when a UNC path is used. A UNC path connection between domains or post offices is less efficient because a message must go through more queues, and because messages are picked up from their queue via a polling process. The method of polling queues isn't nearly as quick or efficient as the TCP/IP transfer method.

A Simplified View of Message Flow

Each of the previous three examples went into quite a bit of detail. This section outlines the file flow for the previous scenarios. Remember, the goal here is to reveal the GroupWise file flow system so that you will be able to troubleshoot problems with message delivery.

Scenario #1: PO1 to PO2 in the Same Domain

In this scenario, a user on PO1 sent a message to a user on PO2. Both PO1 and PO2 are in the same GroupWise domain.

Message: The message transport file passed through each of the following directories in order as it proceeded from PO1 to PO2 for delivery:

  • PO1\WPCSIN\4

  • DOMAIN1\GWINPROG\4

  • DOMAIN1\MSLOCAL\MSHOLD\PO2-FID\4

  • PO2\WPCSOUT\OFS\4

Status message: The status message transport file passed through each of the following directories as it proceeded from PO2 back to the sender's post office, PO1:

  • PO2\WPCSIN\5

  • DOMAIN1\GWINPROG\5

  • DOMAIN1\MSLOCAL\MSHOLD\PO1-FID\5

  • PO2\WPCSOUT\OFS\5

Scenario #2: PO1.DOMAIN1 to PO2.DOMAIN2

In this scenario, a user on PO1 sent a message to a user on PO2. PO1 and PO2 exist in different domains.

Message: The message transport file passed through each of the following directories as it proceeded from PO1 to PO2 for delivery:

  • PO1\WPCSIN\4

  • DOMAIN1\GWINPROG\4

  • DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FID\4

  • DOMAIN2\GWINPROG\4

  • DOMAIN2\MSLOCAL\MSHOLD\PO2-FID\4

  • PO2\WPCSOUT\OFS\4

Status message: The status message transport file passed through each of the following directories as it proceeded from PO2 back to the sender's post office, PO1:

  • PO2\WPCSIN\5

  • DOMAIN2\GWINPROG\5

  • DOMAIN2\MSLOCAL\MSHOLD\DOMAIN1-FID\5

  • DOMAIN1\GWINPROG\5

  • DOMAIN1\MSLOCAL\MSHOLD\PO1-FID\5

  • PO1\WPCSOUT\OFS\5

Scenario #3: PO1.DOMAIN1 to GWIA.DOMAIN2

In this scenario, a user on PO1 sent a message to an Internet address. The GWIA resides on a different domain than the sender's post office.

Message: The message transport file passed through each of the following directories as it proceeded from PO1 to the GWIA (the transmission of the message via SMTP and its ultimate delivery to the Internet recipient are not described here):

  • PO1\WPCSIN\4

  • DOMAIN1\GWINPROG\4

  • DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FID\4

  • DOMAIN2\GWINPROG\4

  • DOMAIN2\MSLOCAL\MSHOLD\GWIA-FID\4

  • DOMAIN2\WPGATE\GWIA\WPCSOUT\GWIA-FID\4

Status message: The status message transport file passed through each of the following directories as it proceeded from the GWIA back to the sender's post office, PO1. Keep in mind that this status message does not indicate that the message was delivered to the Internet recipientonly that the message was successfully transferred to the GWIA's SMTP daemon. These are the directories it proceeded through:

  • DOMAIN2\WPGATE\GWIA\WPCSIN\5

  • DOMAIN2\MSLOCAL\GWINPROG\5

  • DOMAIN2\MSLOCAL\MSHOLD\DOMAIN1-FID\5

  • DOMAIN1\MSLOCAL\GWINPROG\5

  • DOMAIN1\MSLOCAL\MSHOLD\PO1-FID\5

  • PO1\WPCSOUT\OFS\5

You will probably want to bookmark this page. This section's explanation of message flow is something you can refer to if you need to troubleshoot message flow.


Using File Flow for Troubleshooting

The previous sections provided you with a lot of detail about the flow of messages through the GroupWise system. This information might seem a little esoteric, though. This section applies the information to some scenarios in which the GroupWise administrator might need to troubleshoot problems with message flow.

Troubleshooting Scenario #1: Can't Send Internet Email

In this scenario, the users in DOMAIN1.PO1 note that they can send email within the post office but can't send email to recipients on the Internet.

Here are the typical troubleshooting steps taken to resolve this problem:

1. | The first thing the administrator does is check the GWIA on DOMAIN3. Obviously, to send to the Internet, users have to be able to send through the GWIA. It is up and running just fine, though. As a test, the administrator sends a quick message to a side myrealbox.com account. It is delivered.
2. | It occurs to the administrator that perhaps the users cannot send to anyone outside their post office. Rather than having one of these users send a test message, the administrator sends a message to one of the users in DOMAIN1.PO1, as well as to a user on DOMAIN2. The logic here is that by the time status messages have returned from DOMAIN2, they should also have returned from DOMAIN1.
3. | Checking the status of the message, the administrator sees that the message to DOMAIN1 remains in a pending state long after the message to DOMAIN2 showed up as being delivered. This means that something is blocking message flow to or from DOMAIN1.
4. | The administrator decides to focus on DOMAIN1.PO1 first (even though the problem might be with other post offices under that domain as well). Opening the PO1\WPCSIN\4 directory in Windows Explorer, the administrator finds nearly 300 files queued up for transport. The oldest file is nearly an hour old.
5. | The administrator checks the message transfer status on the POA console (see Chapter 8, "Configuring the Post Office Agent," for keystrokes, or view the POA through the HTTP interface to identify this), and the POA claims that the connection with the MTA is up and running. So the problem is not with the connection. However, in checking the message transfer status of the POA through the HTTP interface, the administrator notices that of the 300 files queued up for transport, the oldest file is 320MB.
6. | At this point, the administrator has determined the cause of the problem. Someone sent a huge message, and the POA and/or MTA could not handle the file. Even though these agents are multithreaded, all threads must use the same physical connection between MTA and POA, and in this case, the network link did not have the bandwidth to manage the transfer between the post office and the domain. All other messages sitting in the WPCSIN\4 directory are being held up behind this one.

The solution here is not likely to be pretty. The administrator could try to unload the POA to get it to release the file, but it is unlikely that it will unload cleanly. This means that the server will have to be downed and the file cleared out manually. Still, with the application of good message-flow principles, the administrator can resolve the problem without calling technical support.

Lessons from Troubleshooting Scenario #1

There are some basic GroupWise troubleshooting principles you should take from this scenario:

  • The people who report problems are rarely technicians. Don't expect their information to be accurate. Was the information from the people on PO1 accurate? Well, yes, they couldn't send to the Internet, but the way they experienced the problem could lead you to believe that they were having problems only with Internet email. They were, in fact, having problems sending to anyone outside the post office.

  • Focus at the first point of potential failure. In this scenario, that meant focusing on PO1. If users on PO1 are complaining of a problem, log in as a test user on PO1 and witness the problem for yourself.

  • Think message flow. Users say they cannot send to the Internet. What's the first place from PO1 that a message has to go in order to get to the Internet? The POST OFFICE\WPCSIN\X directories, which is therefore the first place to start looking. If there aren't files in the POST OFFICE\WPCSIN\X directory, keep looking upstream until you find the problem.

Troubleshooting Scenario #2: Can't Send Between Post Offices

In this scenario, Bob on PO1 complains that he cannot send to Mary Baker on PO2. He gets the mail message back with an error D101 (user not found). The administrator troubleshoots by first sending to Mary Baker from his or her own mailbox on PO3. Mary gets the email, and no errors are reported. Now the administrator must watch Bob send a message to Mary. Here's what happens:

  1. Bob starts typing Mary B and the name completion fills in the rest.

  2. The administrator has Bob open the address book. In the GroupWise address book, Mary Baker's entry is not grayed out. The administrator has Bob click the Frequent Contacts book. There he points out the entry for Mary Baker that has been grayed out. The administrator has Bob delete this entry from the frequent contacts list.

  3. Now the administrator has Bob send another message to Mary. Name completion executes as usual, and this time the message is delivered normally.

Lessons from Troubleshooting Scenario #2

Here are a couple more GroupWise troubleshooting principles to take home:

  • Watch your users, if you can. The devil is in the details, as they say, and it is not likely that Bob would have reported the details of name completion to his administrator.

  • Isolate the problem. This likely means running a quick test or two. In this scenario, the administrator had to determine whether it was just Bob who couldn't send to Mary, or whether it was everyone.

  • After you've isolated the problem, apply your architectural knowledge. In this case, an address book entry was incorrect, but it was not in the system address book. Knowing that the frequent contacts list is stored in the user database helped the administrator understand how one (and only one) user might get an error sending to one other user.


Troubleshooting Tips and Tricks

This section describes a few more troubleshooting scenarios you might encounter, as well as discussing how you might deal with them.

X-Locked Files

GroupWise uses a platform-independent mechanism for locking files in transit. When a transport file is in the process of being created, it is often created with a filename that starts with an X. This is called an X-lock.

A GroupWise agent will not touch any file that starts with an X. You are most likely to see X-locked files for an extended period when a big file is being transmitted, or when a link between a sending and a receiving site is slow. If you see a new file (created in the past five minutes or so) beginning with an X, it is most likely still in transit. If the file is more than a day old, however, it is most likely of no value and can be deleted. This was a failed attempt to transmit a file.

Note

You will see files in the MTA's queues by the name of XNSTORE. These are not typical X-locked files. These are actually queue memory files. Here's how the MTA uses them. If the MTA comes up, and discovers that there are hundreds of files (or more) in a queue, it will get a directory listing of the files in the queue and write that directory listing to the XNSTORE file. This way, the MTA does not have to rescan the queue until it has processed all the files referenced in the XNSTORE. This is just one of those fine-tuning procedures that Novell developers do when they're trying to trim off milliseconds from message processing.

TCP/IP Troubles

Suppose for a moment that the POA is having difficulty talking to an MTA via MTP (TCP/IP). You suspect this because people on CORP complain that they cannot send to anyone outside the PO. You can see that the PO1\WPCSIN\4 directory is full of files.

Where might you start? There are a set of logical places to look to determine the problem. Here's the scenario:

CORPPO POA | IP address 137.65.55.211 | MTP inbound port 7101
CORP MTA | IP address 137.65.55.211 | MTP inbound port 7100

Here are the troubleshooting steps you can take to resolve this problem:

1.
Look at the POA; press F10 and choose Message Transfer Status.

Figure 20.1 shows the Message Transfer Status screen on the POA.

Figure 20.1. Message transfer status on a POA

[View full size image]

2.
Look at the configuration status on the MTA by pressing F10 and choosing Configuration Status. Look at the connection to PO1. Figure 20.2 shows this screen.

Figure 20.2. Configuration status on the MTA

[View full size image]

3.
Confirm that the MTA is actually listening on port 7100 by loading TCPCON and choosing Protocol Information, TCP, TCP Connections. Ensure that the local host is using port 7100. Figure 20.3 shows this screen in TCPCON.

Figure 20.3. TCPCON information showing that 7100 is in use

[View full size image]

4.
Confirm that the MTA will receive connections at port 7100.

To do this, run a Telnet program. Be sure to turn on local echo in Telnet, which makes it easier to see what's going on, as shown in Figure 20.4.

Figure 20.4. Telnetting to the MTA's port 7100

[View full size image]

Note

Figure 20.4 is from a Windows 2000 workstation. The Telnet program on Windows NT and 9x is a GUI-based Telnet. You set local from the Terminal, Preferences option.

5.
If you get a connection to port 7100 (see Figure 20.4), enter some characters.

You should then be disconnected. If you don't get disconnected, that's a problem. Perhaps you've found that the MTA is listening on port 7100, but you have no guarantee that the POA can reach the MTA on port 7100. See whether the file server running the POA can ping the server running the MTA. Be sure to change the byte size on the ping packet so that it represents a "normal" sort of transmission size (try 1,000 bytes).

6.
On the file server running the POA, load ping and select the IP address for the box running the MTA, changing the packet size to 1,000 bytes.

7.
Next, load the GWIP.NLM with the syntax LOAD GWIP CONNECT 137.65.55.211 7100 to test the connection to the MTA.

The GWIP.NLM file can be obtained from Novell's support website and is a simple but useful tool to test GroupWise connections. The name of the download file is GWIP.EXE. See Figure 20.5 for a successful GWIP session.

Figure 20.5. A GWIP.NLM session shows a successful connection

[View full size image]

Generally, you'll find the TCP/IP connectivity problem along the way as you use these steps. If the problem continues to elude you, try performing a reinitialize system on the box that houses the POA and the MTA. You can do this while people are connected to the POA.


Best Practices

As always, there are a few things you can do ahead of time that will make your life (and your troubleshooting efforts) easier down the road:

  • Make sure that log files on your GroupWise agents can grow large enough and long enough to give you the diagnostic information you need when you need it.

  • Look for message files in queue directories. The mail message queue directories under a post office are the following:

    • PO\WPCSOUT\OFS\0-7: Incoming messages to the post office.

    • PO\WPCSIN\0-7: Outgoing messages from the post office.

    The mail message queue directories under a domain are the following:

    • DOMAIN\WPCSIN\0-7: These are incoming messages to the domain. These files are placed into the WPCSIN\0-7 directory if another domain has UNC connectivity to this domain.

    • DOMAIN\MSLOCAL\GWINPROG\0-7: When a mail message is incoming to the MTA, it is initially created in these directories.

    • DOMAIN\MSLOCAL\MSHOLD\XXXXXXXX\0-7: These are outgoing messages from the domain. Wherever a mail messages goes to a PO, to another domain, or to a gateway in this domain, it is first routed to the DOMAIN\MSLOCAL\MSHOLD\XXXXXXXX\0-7 directory. The XXXXXXXX value corresponds with the FID of the object whose outgoing queue this represents.

      Tip

      In each of the DOMAIN\MSLOCAL\MSHOLD\XXXXXXXX directories, there is a text file called MTANAME. If you open this file with any text editor, it will give you the full name of the domain or post office that this hold queue represents.

    • DOMAIN\WPGATE\gateway name\WPCSOUT\GATEWAY-FID\0-7: When an MTA has a message to give a gateway, it puts the message in this directory.

    • DOMAIN\WPGATE\GATEWAY\WPCSIN\0-7: When a gateway has something to give the MTA, it puts the file in this directory.

  • If you use Windows Explorer to look at file queues, make sure that Explorer is configured to give you the most accurate information. Otherwise, you might not notice that a file in a particular queue is very large. Make sure that Windows Explorer is configured to do the following:

    • Show all files

    • Sort all files according to size

    • Show the details for files (so that you can actually see the file size)

  • Use the agent's HTTP monitoring interface to help troubleshoot message flow problems. The GroupWise agents HTTP interface allows you to very quickly and easily determine whether and where you are having link configuration problems. You can track the links through your system, and easily see whether there are any messages queued up in any of an agent's hold queues.

    One other tip is that if you have message logging enabled on the MTA and you see messages sitting in an MSLOCAL\MSHOLD\XXXXXXXX directory, you can actually click the messages. You can then determine who the sender of the message is.


Summary

This chapter covered a lot of information, but it can all be distilled into three basic troubleshooting principles. When you need to troubleshoot GroupWise message flow, you need to do the following:

  • Check the queue directories for "stuck" files, backlogs, and so on.

  • Check the POA and MTA logs for error messages, or track message DRNs.

  • Check each of the connectivity pointsTCP/IP connections between POAs and MTAs, links between MTAs on different domains, and any other links that are part of the signal path for the problem messages.

Remember, one of the easiest ways to check message flow is to send a message and then check its status. Pending status means that the flow has been blocked at some point. Any other status means that message flow is open between your mailbox and the destination mailbox.


Chapter 21. Moving Domains and Post Offices

This chapter walks you through the process of moving post offices and domains to new servers (new UNC paths), as well as moving their objects around within your eDirectory tree. This isn't something you will do often, but you will not find these procedures documented in such detail in any other place.


Considerations Related to Moving a Domain

When moving domains, you are going to move a domain from one physical UNC location to another. Generally, the move is from one file server to another. This discussion assumes that the domain will be moved from one file server to another, typically of the same server type (NetWare to NetWare, or Windows to Windows). This chapter does not cover moving a domain or post office from NetWare or Windows to Linux. Here is the scenario:

  • The domain to be moved is DOMAINX.

  • DOMAINX is a secondary domain.

  • DOMAINA is the primary domain in this system.

  • The file server where DOMAINX originally resided is called FS1.

  • The file server where DOMAINX will reside is called FS2.

  • The old location of DOMAINX is \\FS1\EMAIL\DOMAIN.

  • The new location of DOMAINX is \\FS2\EMAIL\DOMAIN.

That's the scenario; the next few sections talk about important preparatory steps to take.

Connectivity to the Primary Domain

One of the biggest concerns when moving a domain is the manner in which the new location for DOMAINX will be communicated to the rest of the system. Suppose that DOMAINX communicates to the rest of the GroupWise system via TCP/IP. The new file server, FS2, will have a different IP address than FS1. This needs to be communicated to the rest of the system before DOMAINX is moved. So the message transfer agent (MTA) object for DOMAINX must be edited, and the network address field should indicate the IP address for FS2. Just as soon as the IP address for DOMAINX's MTA has been changed, the rest of the system expects to communicate with DOMAINX at the new IP address.

Any changes made to the IP address for the MTA on DOMAINX should be done with ConsoleOne physically connected to the WPDOMAIN.DB for DOMAINX. If you were to change the IP address for the MTA on DOMAINX while connected to the primary domain, your primary domain MTA would immediately restart but would not be able to communicate the change to DOMAINX's MTA if DOMAINX was not running on the new file server.

Communication between DOMAINX and the primary domain is the most important communications link. If the primary domain cannot communicate with DOMAINX in order to get the information about DOMAINX's new MTA IP address, no one is going to get the change. Make sure that DOMAINX can communicate with the primary domain.

Connectivity to Post Offices

When a domain is moved to a new IP address, its post offices must be informed of the change to the MTA's IP address in order for the post office agent (POA) to be able to communicate with the MTA.

Moving a Domain to a New Server

The following is a sample task list for moving DOMAINX. The discussion can help you apply these concepts to your own domain moves.

Warning

If the domain you want to move houses a GroupWise WebAccess gateway, you must delete the GroupWise WebAccess gateway first before moving the domain. A GroupWise WebAccess gateway cannot be moved along with its domain. You must reinstall and reconfigure the GroupWise WebAccess gateway.

DOMAINX is being moved from the file server called FS1 to the file server called FS2. DOMAINX has two post offices that it communicates with via TCP/IP. Another name for TCP/IP connectivity to a POA is MTP connectivity.

As a precautionary step, you'll want to sync DOMAINX with the primary domain. Following are the steps for syncing a secondary domain with the primary domain:

1.
In ConsoleOne, connect to WPDOMAIN.DB for the primary domain, highlight DOMAINX, and choose Tools, GroupWise Utilities, System Maintenance.

2.
Select Sync Primary with Secondary and then click Run.

Next, you'll want to install the GroupWise agents to FS2 (explained in step 3).

3.
Install the GroupWise Agent software:

NetWare/Windows:

Go to the Software Distribution Directory\AGENTS directory and run INSTALL.EXE. Run all the way through the installation.

Linux:

Go to the Software Distribution Directory and run the install script.

Tip

When you perform the agent install, you will be prompted to enter the domains or post offices you are installing the agents for. If you do not enter or define any domains or post offices for the agent install, the installation process installs only the agent files. This is exactly what you want in this situation. In the next step, you will be copying the MTA's startup file. When you define the path to domains or post offices during the install routine of the agents, a new startup file is built by the install routine.

4.
Copy the startup file for the GroupWise MTA from \\FS1\SYS\SYSTEM to \\FS2\SYS\SYSTEM.

5.
Edit the MTA startup file in \\FS2\SYS\SYSTEM and make sure that the home switch points to the new domain directory. Also see whether the /log switch is enabled. If it is, make sure that the path indicates a location on FS2.

6.
If you intend to load the GroupWise MTA from the AUTOEXEC.NCF file of your NetWare file server, make sure you have a reference to this (for example, a reference within the file to GRPWISE.NCF). Make sure that GRPWISE.NCF loads the GroupWise MTA in conjunction with the startup file you have configured for the MTA.

7.
Load ConsoleOne and connect to DOMAINX in the GroupWise system view. This is done by going to Tools, GroupWise System Operations. Select Domain and then select the path to DOMAINX.

Even though you haven't moved the domain, make sure that DOMAINX and the primary domain can communicate. You can use steps 8 through 11 to confirm that this is the case.

8.
Edit DOMAINX's MTA, and on the Agent Settings property page increment the Attach Retry option by one second. Usually this setting is 600; set it to 601.

9.
Connect to the primary domain in ConsoleOne, edit DOMAINX's MTA, and find out whether the Attach Retry value changed on DOMAINX's MTA object.

Tip

The purpose behind incrementing the Attach Retry option specifically is that this value is not held in eDirectory. When you confirm that the change to this setting has actually replicated, you know that GroupWise directory replication is working.

Do not proceed to the next step until you confirm that this change has been replicated to the primary domain. Get in and out of the MTA object to verify the change.

Note

If you're moving the primary domain, you don't have to worry about whether there is communication with the primary domain, of course.

10.
In ConsoleOne, connect back to DOMAINX's WPDOMAIN.DB file.

11.
Edit DOMAINX's MTA and change the TCP/IP address in the network address option to reflect FS2's IP address (see Figure 21.1).

Figure 21.1. Change the network address on the MTA to reflect the new file server

[View full size image]

It might sound strange to change the IP address of an MTA to reflect the IP address on a server on which the MTA is not running; but don't worry, it will work. The whole idea is that the MTA that is currently running on FS1 will communicate the change in the IP address before the MTA goes down. DOMAINX's MTA will be able to connect with the rest of the MTAs in the system, but they will lose connectivity to DOMAINX's MTA. This condition is just fine. Wait for about five minutes for this information to replicate before going to the next steps.

12.
Exit ConsoleOne.

13.
Bring down DOMAINX's MTA and any gateways running for DOMAINX.

14.
Make sure that no one is accessing WPDOMAIN.DB.

Here is a simple test: Try to rename the WPDOMAIN.DB file to WPDOMAIN.REN and then back to WPDOMAIN.DB. If you can't rename the file, do not proceed until you can. NetWare server administrators can check file/open lock activity on the server monitor program to see which users still have a connection to the domain database. You then know who still has the domain database open. If the connection to the WPDOMAIN.DB happens to be 0, there is a process on the server that is holding the WPDOMAIN.DB file open.

15.
Copy the domain directory from the old location to the new location.

Copy the \\FS1\EMAIL\DOMAIN\ directory to \\FS2\EMAIL\DOMAIN using one of the following options (in preferred order):

  • Use a backup of the domain from FS1 and then restore it to FS2. This is most often the fastest method, and this way you will also make sure once again that your restore procedure works as designed; after all, what's the use of a backup if you never test your restore?

  • Use NCOPY *.* /S /E. (NCOPY is superior to COPY or XCOPY because it performs a server-to-server copy, which is faster.)

  • Use XCOPY *.* /S /E.

  • Use Windows Explorer to copy and paste the directory, and then watch the flying pages!

16.
Rename the WPDOMAIN.DB file on FS1 to WPDOMAIN.BAK.

17.
Load ConsoleOne. You should get an error stating that the domain database for DOMAINX cannot be found. This is okay.

18.
Connect to the now-relocated DOMAINX domain's WPDOMAIN.DB file, and when ConsoleOne asks you for the path to the domain, browse to the domain's new UNC location.

19.
Edit DOMAINX's object as shown in Figure 21.2, and change the domain's UNC path to reflect the new path for DOMAINX.

Figure 21.2. Changing the UNC path to reflect the newly moved domain

[View full size image]

20.
Edit DOMAINX's MTA. Go to the Log Settings property page. If you have specified a path, make sure that it reflects the UNC path where the domain is located. You should also check the Message Log setting and update this path if you have entered a path here.

21.
Bring up the MTA for DOMAINX on FS2.

22.
Get the POAs and the MTA talking via TCP/IP.

You might have to restart the POA's MTP threads that service post offices that are in DOMAINX. Although the IP address for the MTA might have been communicated to the POA, the POA might not restart the MTP process to use the new address. The MTP process might show the domain being closed. The GroupWise POA allows you to restart just the MTP threads. This is done through F10, Actions, Restart MTP threads.

After restarting the MTP threads, see whether it shows the new MTA's IP address. To do this, press F10 and choose Message Transfer Status.

If the IP address is incorrect, you need to become a little bit more forceful with the POA. One option is to rebuild the WPHOST.DB file to force the information down to the post office. You can also use the information in the following tip for another resolution to this problem.

Tip

If you cannot get your POA to understand that the MTA has a new IP address, or you do not want to rebuild the WPHOST.DB file, you might want to just use the HTTP interface of the POA to edit the IP address and port. This can be done by accessing the POA's HTTP interface. Click the Configuration tab, and then scroll down and click the Message Transfer Protocol link. This will take you to a screen where you can edit the in- and outbound IP address and port on which the POA listens. Edit the IP address you need here, and then make sure you click the Restart MTP option and click Submit. If you do not select the option to restart MTP, the change will not take effect.

If you are not using the HTTP interface option to the POA, you can also use the following switches in the POA's startup file to force the POA to cooperate:

/MTPINIPADDR-IP address of the POA
/MTPINPORT-MTP port of the POA
/MTPOUTIPADDR-IP address of the MTA
/MTPOUTPORT-IP port of the MTA

For example:

/mtpinipaddr-137.65.55.210
/mtpinport-7101
/mtpoutipaddr-137.65.55.213
/mtpoutport-7100

23.
If the server is a NetWare server, configure the NetWare server to run more efficiently with the new GroupWise domain by setting the following directories, and the subdirectories off of these directories, for immediate purge of deleted files:

\\FS2\EMAIL\DOMAIN\WPCSIN
\\FS2\EMAIL\DOMAIN\WPCSOUT
\\FS2\EMAIL\DOMAIN\MSLOCAL
\\FS2\EMAIL\DOMAIN\WPGATE\gateway\WPCSIN
\\FS2\EMAIL\DOMAIN\WPGATE\gateway\WPCSOUT

24.
Finally, you must regraft the domain object. This will ensure that the domain's new UNC path is reflected in eDirectory. To do this, go to the eDirectory browser view (not the GroupWise view) and follow these steps:

  1. Highlight the eDirectory Organizational Unit (OU) that houses DOMAINX.

  2. Select Tools, GroupWise Utilities, GW/eDirectory Association, Graft GroupWise Objects.

  3. Select domains, post offices, and gateways.

  4. Proceed through the grafting wizard, and make sure to graft DOMAINX; you do not need to graft the users associated with DOMAINX.

Your domain should now be successfully moved. To test whether it is, make sure that you can connect to the domain in ConsoleOne, and that all other MTAs show this domain as open. You should also make sure that all post offices off of this domain show the domain as open.

Final Notes on Moving a Domain

The example in the preceding section is not a perfect fit for every situation. For example, some sites have implemented domain name service (DNS) names for their MTAs rather than IP addresses. The DNS name simplifies the IP address change, because the only IP address that needs to change is in the DNS's translation table.

Also, if you have a gateway below a domain that needs to be moved, you will need to see that the gateway is configured for new changes to the IP address or the new UNC path for the domain. Consider, for example, a domain with a GWIA. If you are moving the domain that a GWIA is associated with, you have to do the following:

1.
Copy the GWIA's executable code to the new server.

To install the GWIA code to a new server without using the wizard to install a new GWIA, go to the Software Distribution Directory and run the INSTALL.EXE file from the Software Distribution Directory with the /COPYONLY switch. Here's the exact syntax:

SDD UNC PATH\INTERNET\GWIA\install.exe /copyonly

2.
Copy the GWIA.CFG file to the new file serverthis file is typically in the SYS:SYSTEM directory on a NetWare serverand then modify the GWIA.CFG file so that it reflects the correct paths to the domain. On a Linux server, the GWIA.CFG file is generally located at the path /opt/novell/groupwise/agents/share.

3.
Modify the EXEPATH.CFG file to reflect the new path to the GWIA.CFG file.

The EXEPATH.CFG file is in DOMAIN THAT OWNS THE GWIA\WPGATE\GWIA DIRECTORY.

Note

For more information on what's in the GWIA.CFG and EXEPATH.CFG files, see Chapter 10, "Installing and Configuring the GroupWise Internet Agent."

4.
Edit the GWIA. Go to the Log Settings property page and make sure that the log path does not reflect the old UNC path.

5.
Edit the GWIA. Go to the Network Address page, and make sure that the new network address for the GWIA is indicated.


Considerations Related to Moving a Post Office

First of all, it's impossible to move a GroupWise post office to a different domain. If you are reorganizing and need to move a post office to a new domain, you need to create the post office anew in the new domain and move all the users to the new post office. Have a look at Chapter 13, "Moving Users," if this is what you need to do.

This discussion talks about moving a GroupWise post office. You are going to be moving a post office from one physical UNC location to another. Here is the information from the scenario:

  • The post office to be moved is called PO-X.

  • DOMAINA is the domain that owns post office PO-X.

  • The file server on which PO-X originally resided is called FS1.

  • The file server on which PO-X will reside is called FS2.

  • The old location of PO-X is \\FS1\EMAIL\PO.

  • The new location of PO-X is \\FS2\EMAIL\PO.

That's the scenario; the next few sections talk about important preparatory steps to take.

GroupWise Client Connectivity

Most customers have configured their post offices to support client/server connections from the GroupWise client to the GroupWise POA. The GroupWise client knows that it must contact the GroupWise POA via an IP address. Each time the GroupWise client loads, it reads the IP address out of one of the following locations:

  • eDirectory

  • The Windows Registry where the GroupWise 32-bit client is installed

  • In the USER.DB file for any GroupWise caching or remote client

If these locations don't provide the client with a valid IP address, it might check domain name services (DNS) for the NGWNAMESERVER POA.

Note

If the local machine has a value defined in the Registry at HKLM\SOFTWARE\Novell\GroupWise\Client\5.0\DefaultIPAddress and DefaultIPPort, the GroupWise client will not check NGWNAMESERVER to find a POA.

The trick is to communicate the new IP address to all GroupWise clients. If you specified the IP address for the POA using a DNS name (for example, POA.POX.WORLDWIDEWIDGETS.COM), the change is an easy one. Just change the DNS translation table for POA.POX.WORLDWIDEWIDGETS.COM so that it reflects the new IP address of the POA when running on FS2. In this way, the settings that the clients have stored will still be correct. The client will look to DNS to resolve the hostname the same way it did before the PO was moved, and DNS will give the client the new address.

If you have specified the IP address for the POA using numbers (which most customers do), for example 10.100.221.2, you have to depend on the client to perform an eDirectory lookup, or a DNS lookup for NGWNAMESERVER. This walkthrough shows you how to configure your system so that those lookups succeed.

DomaintoPost Office Connectivity

The GroupWise MTA for DOMAINA has to know how to connect to the PO-X post office. Otherwise, messages will not move from the DOMAINA MTA to the POA running on PO-X.

GroupWise WebAccess and GWIA Connectivity

Your GroupWise WebAccess Agent needs to know about the change to PO-X's location and/or IP address. If your GWIA is configured for POP3 or IMAP4 support, it will also need to know how to get hold of the newly moved PO-X post office. These two gateways connect directly to the post office to provide alternative types of mailbox access, as discussed in Chapter 10 and Chapter 11. If they do not know about the post office's POA's new IP address, you will have WebAccess, POP3, or IMAP4 users who cannot get to their mail.

Libraries with Additional Document Storage Areas

If a library is contained in the post office you're moving, you might have an additional concern. Usually, you can simply copy the entire post-office structure, library directories and all, and be fine. The problem comes in when there are document storage areas (DSAs) defined outside of the post office directory.

If the DSA needs to be moved, consult Novell's knowledgebase to see what caveats the latest GroupWise code may have with moving a Document Storage Area. DSA Moves can occur independently of post office moves. If the DSA does not need to be moved, all you need to do is make sure that, when the POA runs at the new location, it still has full access to the DSA.

If you are moving a post office to a Linux server, please be aware that a GroupWise for Linux post office cannot have a Document Storage Area outside of the post office.

Warning

If you move a post office to a new location but keep the DSA at the old server path, you might have problems loading your GroupWise POA. You might get a DF17 error, and the POA will not load. You need to correct the DF17 error; but to get things up and running, you can add a /noconfig switch to the POA's startup file. You still must make sure that the POA can connect to the DSA.

The Software Distribution Directory (SDD)

Software Distribution Directories are similar to document storage areas in that they can be moved independently of the post office. You have three basic options with regard to your Software Distribution Directory:

  • Assign the PO to a new Software Distribution Directory. It might be that with the PO move, a different server is used to deliver applications to users. If there is another SDD there, it makes sense to assign that one to the PO you are moving.

    Warning

    If you assign a post office to a new Software Distribution Directory, keep in mind the bump and build numbers. If you do not want your users to get prompted to update the GroupWise client, make sure that the BUILD number is tweaked accordingly. See Chapter 12, "Administering the GroupWise Client," for more details on the bump and build numbers.

  • Move the Software Distribution Directory. This should be your choice if the SDD resides on the same server as the users. In this case, you need to copy the SDD to the new server and edit the path of the SDD using the software directory management tool discussed in Chapters 6, "Using GroupWise System Operations," and 8, "Configuring the Post Office Agent."

This section talked about all the things to keep in mind when moving a post office. The next sections include an actual scenario for moving a post office.


Moving a GroupWise Post Office to a New UNC Path

Here is the scenario: The GroupWise post office PO-X is being moved from FS1 to FS2. The file server housing PO-X isn't robust enough, so you must put the GroupWise post office on its own dedicated NetWare server. The PO-X post office communicates via TCP/IP to its owning domain, DOMAINX. All users access PO-X in client/server mode.

Moving the Post Office and Creating Domain-to-PO Connectivity

A few days before the post office move, let users know that the move of the post office will happen. If everything goes well, it should be rather seamless for most users. Unless you are using DNS names to identify where the POA is running, users who use GroupWise caching or remote mailboxes need to manually change the IP address to the POA under Accounts, Account Options, Properties, Advanced.

Tip

If when you rolled out your GroupWise clients, you defined the DefaultIPAddress and DefaultIPPort settings in the SETUP.CFG file to point to a DNS name of a post office, the cache and remote users will not need to reconfigure where their remote and cache clients attempt to connect to. The remote or cache client will attempt to connect to the old post office IP address. If this fails, and the Registry keys for DefaultIPAddress and DefaultIPPort are present on the machine, the remote or cache client will attempt to connect here before failing. This provides a great solution to your GroupWise remote and cache users. See Chapter 12 for more information on using the SETUP.CFG file with the DefaultIPAddress and DefaultIPPort parameters.

Here are the steps to follow:

1.
Install the GroupWise POA software to FS2.

You can do this by running the agent install program, INSTALL.EXE, found in the AGENTS subdirectory of your GroupWise CD or SDD.

Tip

When you perform the agent install, you will be prompted to enter the domains or post offices you are installing the agents for. If you do not enter or define any domains or post offices for the agent install, the installation will only install the agent files. This is exactly what you want in this situation, because in the next step you will be copying the POA startup file. When you define the path to domains or post offices during the install routine of the agents, a new startup file is built by the install routine.

2.
Copy the POA's startup file from \\FS1\SYS\SYSTEM to \\FS2\SYS\SYSTEM.

3.
Edit the POA's startup file and change the home switch to reflect the new UNC path for PO-X. Now you need to suspend connectivity from DOMAINA's MTA to PO-X.

4.
Go to the MTA's screen at the NetWare console, press F10, and select Configuration Status.

5.
Highlight the post office PO-X, press Enter, and select the Suspend option.

6.
Bring down the POA that services PO-X.

7.
Rename the WPHOST.DB file in \\FS1\EMAIL\PO to WPHOST.BAK.

Do not proceed until you have done the rename successfully. If you cannot rename the WPHOST.DB file, either there is another POA running against the post office (maybe an indexer POA), or there are users logged in via direct mode who have a connection to it. Check file/open lock activity from the NetWare server monitor to determine who has a connection to the database.

8.
Copy the contents and subdirectories of \\FS1\EMAIL\PO to \\FS2\EMAIL\PO, using one of the following options (in the preferred order):

  • Use a backup of the post office from FS1 and then restore it to FS2.

  • Use Novell's GroupWise DBCOPY utility

  • Use NCOPY /S /E.

  • Use XCOPY /S /E.

  • Copy the data using Windows Explorer.

9.
Load ConsoleOne and make sure you are connected to the WPDOMAIN.DB for DOMAINA.

10.
Edit the post office object in ConsoleOne and change the UNC path to the post office, as shown in Figure 21.3.

Figure 21.3. Changing the UNC path for the post office

[View full size image]

11.
Edit the POA for the PO-X post office and change the IP address in the Network Address tab to reflect the IP address for FS2.

Now you need to check the network links to PO-X to see whether the change to the IP address made it to the link table.

12.
Choose Tools, GroupWise Utilities, Link Configuration. Select DOMAINA, and then choose View, Post Office Links.

You need to double-click the post office link to PO-X to make sure that it has the correct IP address.

13.
Rebuild PO-X's WPHOST.DB file by highlighting the post office and choosing Tools, GroupWise Utilities, System Maintenance. Then select Rebuild Database and click Run.

14.
If your post office is configured for LDAP or SSL, and you have certificate and key files that you use for encryption, be sure to copy them over to the new server. For example, you may be copying the files from \\FS1\SYS:\SYSTEM to \\FS2\SYS:\SYSTEM.

15.
Bring down the MTA for DOMAINA, and bring it back up again.

16.
Bring up the POA for PO-X on FS2 to confirm that the POA can connect to the domain.

The POA for PO-X is configured for MTP, so to test connectivity you do the following:

  • Go to the POA at the NetWare console.

  • Press F10 and then select Message Transfer Status.

  • Confirm that the IP addresses are correct and that communication is established.

Now, you can confirm WebAccess and GWIA connectivity to the post office.

17.
Edit the WebAccess gateway object.

18.
Select the Post Office Links property page.

19.
Highlight the link to PO-X and edit it, making sure that the link reflects FS2's new information.

20.
Edit the GWIA gateway object.

21.
Select the Post Office Links property page.

22.
Highlight the link to PO-X and edit it, making sure that the link reflects the new information for FS2.

Finally, you can create client connectivity as explained in the next steps.

23.
Make sure that all users have browse, read, and compare eDirectory object rights to the post office and POA objects.

This way, if they are running the NetWare client and are in client/server-online mode, they will discover the location to the new POA. For users who do not have the NetWare client, you have hopefully set up the DefaultIPAddress and DefaultIPPort options in the SETUP.CFG file so that they will use a DNS name to locate their post offices. If not, you will have to push out the IP address to the users in some other way. For example, if you have a method of changing the user's Registry, like Novell ZENworks, you can modify the Registry at the following location to reflect the new TCP/IP address:

HKEY_CURRENT_USER\Software\Novell\GroupWise\Login Parameters
\TCP/IP Address

24.
Remember also that if you have not used the DefaultIPAddress and DefaultIPPort settings, the GroupWise caching and remote clients might need to manually change the IP address to the POA. You do this from Accounts, Account Options, Properties, Advanced.

You might need to take additional steps related to the post office move, as explained in earlier sections. And then your post office move is complete. The next section is not required as part of a post office move.

Moving a Post Office to a New OU

As your eDirectory tree evolves and grows, you might need to move a GroupWise post office object to a new OU. The GroupWise software does not readily allow for this task, but this section shows you how to pull it off.

To begin, you need to disable the ConsoleOne GroupWise snap-ins by doing the following:

1.
Get out of ConsoleOne.

2.
From Windows Explorer, move the GROUPWISE folder and its contents from the NOVELL\CONSOLEONE\VERSION\SNAPINS directory into C:\TEMP, or some other location, as long as it's not under the ConsoleOne path.

3.
Reconfirm that there is no longer a GROUPWISE folder in the SNAPINS folder.

When ConsoleOne is unsnapped from GroupWise, all GroupWise objects show up with an icon that looks like a question mark on the right side of a 3D box, as shown in Figure 21.4.

Figure 21.4. ConsoleOne without GroupWise snap-ins

[View full size image]

4.
Start ConsoleOne, and make sure that under the Tools menu there are no GroupWise menus, as shown in Figure 21.4.

5.
Delete the GroupWise POA object by highlighting and deleting the post office object, which appears to the right in Console View.

Figure 21.5 shows the POA object.

Figure 21.5. The POA object with ConsoleOne unsnapped from GroupWise

[View full size image]

6.
Delete any GroupWise libraries that are associated with this post office.

GroupWise libraries will be in the same eDirectory context as the post office object, so highlight a library and delete the object.

7.
Delete the post office object from eDirectory (see Figure 21.6).

Figure 21.6. Deleting the GroupWise post office object

[View full size image]

8.
Put the GroupWise snap-ins for ConsoleOne back into place by moving the GROUPWISE folder from the temporary location back to the NOVELL\CONSOLEONE\VERSION\SNAPINS directory.

9.
Launch ConsoleOne. The GroupWise snap-ins should now be reenabled.

10.
Be sure to connect the domain owning the post office you are moving.

11.
Go into the eDirectory browser view and highlight the eDirectory OU that you want to move the post office into.

12.
Choose Tools, GroupWise Utilities, GW/eDirectory Association, Graft GroupWise Objects.

13.
Select domains, post offices, and gateways.

14.
When prompted with the Select Domain window, select the domain that owns the post office you deleted from eDirectory.

15.
Proceed to the Post Office Context window, shown in Figure 21.7.

Figure 21.7. The Post Office Context window in the Graft utility

[View full size image]

Notice that the Edit Context button will not be grayed out when you highlight the post office that was deleted.

16.
Edit the context and specify the new context for the post office object, if needed.

17.
Click Next and then Finish.

18.
After the graft is finished, get out of the Graft utility, and then get out of ConsoleOne. Relaunch ConsoleOne.

Tip

Getting in and out of ConsoleOne gives ConsoleOne a chance to reread everything; otherwise, ConsoleOne can become confused after a procedure such as this.

19.
Go to the eDirectory context that now houses your post office.

20.
Choose Tools, GroupWise Utilities, GW/eDirectory Association, Graft GroupWise Objects.

21.
When the graft utility comes up, graft the users associated with the relocated post office by selecting users, resources, and distribution lists from the first graft screen.

22.
Proceed through the Graft utility and follow the prompts, choosing the post office that you just moved to a new eDirectory OU as the post office for which the objects need to be grafted, as shown in Figure 21.8.

Figure 21.8. Selecting which objects associated with a post office to graft

[View full size image]

To determine whether your post office graft operation was successful, edit the post office object and look at the Membership page. If you see the users on the post office in the Membership page, you know that the graft was successful.


Moving a Domain to a New OU

As your eDirectory tree changes, you might need to move a GroupWise domain object to a new OU. As with the post office OU move explained earlier in this chapter, the GroupWise software does not have a built-in function to allow for this kind of a move. You'll do this just like you moved the post office to a new OU.

Note

When you're moving a GroupWise domain, the domain object must be deleted from eDirectory. The fact that the domain is deleted from eDirectory throws eDirectory off when trying to understand the GroupWise post office object. So when deleting a GroupWise domain object, you must also delete the post office objects along with the POAs and libraries.

Following are the steps for moving a GroupWise domain to a new eDirectory OU. You first need to disable the ConsoleOne GroupWise snap-ins. After that, follow these steps:

1.
Exit ConsoleOne.

2.
From Windows Explorer, move the GROUPWISE folder and its contents from the NOVELL\CONSOLEONE\VERSION\SNAPINS directory to C:\TEMP.

3.
Reconfirm that there is no longer a GROUPWISE folder in the SNAPINS folder.

When ConsoleOne is unsnapped from GroupWise, all GroupWise objects show up with an icon that looks like a question mark on the right side of a 3D box.

4.
Start ConsoleOne and make sure that under the Tools menu there are no GroupWise menus, as shown in Figure 21.9.

Figure 21.9. ConsoleOne without GroupWise snap-ins

[View full size image]

5.
Delete the GroupWise MTA object of the domain you moved.

To do this, highlight the GroupWise domain object on the right side. The MTA will show up on the left side, as shown in Figure 21.10.

Figure 21.10. The MTA object with ConsoleOne unsnapped from GroupWise

[View full size image]

6.
Delete any gateways or provider objects associated with this domain.

Gateways and provider objects are shown on the right side, in the same place the MTA is.

7.
Delete any GroupWise post offices that are associated with this domain.

Refer to the preceding section, "Moving a Post Office to a New OU," for complete instructions on how to do this. You do not have to actually move the post office to a new eDirectory OU, but you must go through the process of removing the post office object from eDirectory and then regrafting it to eDirectory.

Note

The GroupWise post office object might be in a different eDirectory organizational unit than the GroupWise domain.

Note

You will need to delete all other objects subordinate to the domain being moved. The GroupWise post offices are not truly subordinate to the GroupWise domain in eDirectory. The GroupWise post office must still be deleted because eDirectory gets thrown off if information in the GroupWise post office points back to the deleted GroupWise domain. This does not mean that you need to delete the users; it just means that you'll have to delete the post office POAs subordinate to your post offices.

8.
Delete the domain object from eDirectory.

9.
Put the GroupWise snap-ins for ConsoleOne back into place by moving the GROUPWISE folder from the temporary location back to the NOVELL\CONSOLEONE\VERSION\SNAPINS directory.

10.
Launch ConsoleOne. The GroupWise snap-ins should now be reenabled.

11.
Make sure you are connected to the domain that's moving.

12.
Go into the eDirectory browser view and highlight the eDirectory OU that you want to move the domain object into.

13.
Choose Tools, GroupWise Utilities, GW/eDirectory Association, Graft GroupWise Objects.

14.
Select domains, post offices, and gateways.

15.
When prompted with the Select Domain window, select the domain you deleted from eDirectory.

16.
Proceed to the Domain Context window, shown in Figure 21.11.

Figure 21.11. The Domain Context window in the Graft utility

[View full size image]

17.
Edit the context and specify the new context for the domain object. If you selected the correct context in step 11, the context should be correct here.

18.
Specify the context to place your post offices in. Click Next and then Finish. Once again, if you have deleted the post office and POA eDirectory objects under this domain, the context will default to the same context as the domain. You might need to modify the context for each post office.

19.
After the graft is finished, get out of the Graft utility, and then get out of ConsoleOne and go back in.

20.
Go to the eDirectory context that now houses your domain.

21.
Choose Tools, GroupWise Utilities, GW/eDirectory Association, Graft GroupWise Objects.

Note

Grafting users will not put them into the same context that the domain is in. Actually, you are just regrafting the users in their original contexts.

22.
When the graft utility comes up, graft the users associated with all the post offices below the domain you just moved. You do so by selecting users, resources, and distribution lists from the first graft screen.

Tip

You can simply graft the users for one post office at a time, if that would be easier.

Be sure to specify the correct context for resources and distribution lists. Any libraries will be placed in the resource context you specify.

23.
Finish grafting the users.

As this section showed, moving a domain to a new eDirectory OU is no small process. To move a domain to a new eDirectory OU, all post offices must be removed from eDirectory and then regrafted along with the domain.


Summary

Moving GroupWise domains and post offices around in a Novell eDirectory tree is difficult because there is a lot of detail you need to pay attention to. Be sure to perform all the steps mentioned in the walkthroughs, and your domain and post office moves should be trouble free.

You should also give consideration to who has what rights in the new eDirectory OU that now houses the moved domain or post office object.


Chapter 22. Troubleshooting the GroupWise Directory

The GroupWise directory, sometimes referred to as GDS, is largely contained in the WPDOMAIN.DB and WPHOST.DB files. Typically, the most effective way to fix problems in GroupWise directory databases is by rebuilding them using system maintenance in ConsoleOne.


Using the Correct Tools

GroupWise administrators are often unclear about which tools to use to fix a GroupWise problem. When a problem appears in the system address book in the GroupWise client, running the Mailbox/Library Maintenance or GroupWise check (GWCheck) will accomplish nothing. These are the wrong tools to use to fix GroupWise system address book/WPHOST.DB problems.

Reviewing the discussion of GroupWise architecture from Part I for just a moment, there are two kinds of GroupWise databases:

  • GroupWise directory databases: WPDOMAIN.DB and WPHOST.DB files.

  • GroupWise message/information store databases: These are the *.DB files at any post office, excluding the WPHOST.DB file.

Mailbox/library maintenance, or GWCheck, is strictly for fixing message store databases. The tool for fixing the GroupWise directory databases is called System Maintenance. As discussed in Chapter 7, "GroupWise Utilities and Diagnostics," you find this tool by choosing GroupWise Utilities from the Tools menu.

Tip

If your system is on multiple platforms, for example, NetWare and Linux, you need to take into consideration whether your filenames are in upper- or lowercase. On NetWare and the Windows platform, the case of the WPDOMAIN.DB and the WPHOST.DB does not really matter. On the Linux platform, the case of these files should always be lowercase. So after you have rebuilt one of these databases, make sure that the file is in lowercase format if it will be placed on a Linux server.


Fixing WPHOST.DB Files

To discuss repairing a post office database (WPHOST.DB), it's best to look at some examples. The scenarios in this section will help you explore the different options for system maintenance on a WPHOST.DB file.

System Maintenance: Validate, Recover, and Rebuild

For scenario #1, a post office agent (POA) of a particular post office supporting 400 users is attempting to load. It will not load; instead, it produces a C022 error.

When the GroupWise POA of any post office loads, it first interacts with the WPHOST.DB file, and then loads the NGWGUARD.DB file. The question is which one of those files is to blame for the C022 error? Well, it's hard to tell. You might suspect that the WPHOST.DB file is damaged. If you rebuild the WPHOST.DB file, there's a 50% chance you'll fix the problem. Your WPHOST.DB file is 48MB, and in the past, rebuilding this file has taken about an hour; an expensive proposition when you only think the problem is the WPHOST.DB file!

A better solution is to use the Validate Database option from the System Maintenance tool (see Figure 22.1).

Figure 22.1. Validate Database is the first choice on the GroupWise System Maintenance menu

Tip

Chapter 7 discusses how the choices in the System Maintenance menu can be used.

The Validate Database routine runs a quick structural analysis of a WPHOST.DB file to see whether it is physically consistent. The validate routine usually takes under a minute.

One possible outcome when you run the Validate Database routine is to get the error shown in Figure 22.2.

Figure 22.2. An error can occur during validation of a WPHOST.DB file

If this error appears, you know that your theory was rightthe WPHOST.DB file is damaged, and rebuilding it is the appropriate course of action.

For scenario #2, Mary Smith's name has changed to Mary Jones. You changed her name, but in one post office's address book, Mary's name will not change to Mary Jones.

In this kind of a scenario, you should be less likely to immediately suspect gross structural damage to the WPHOST.DB file. It is more likely that, for some reason, Mary's change isn't being sent down to the post office. Perhaps there is a message-flow problem. The simplest course of action is the following:

  1. Synchronize Mary's object. Highlight it, select the Tools menu, and choose GroupWise Utilities, Synchronize.

  2. Watch the POA for the post office on which Mary's name did not change.

In this fictitious example, the POA reports a DB xx error (the xx represents any two characters) when trying to update Mary's object. The question becomes whether Mary's is the only object in this WPHOST.DB file that can't be updated. You need to determine whether you can change information about other users.

To troubleshoot this possibility, the administrator will do the following:

  1. Synchronize another user.

  2. Watch the POA for the post office on which Mary's name did not change.

Suppose that the POA didn't report an error when rewriting this other user object to the WPHOST.DB file. However, on further investigation in the POA log file, you do see other DB xx errors on user objects besides Mary's.

You can conclude that there is definitely a problem with Mary's object in this one WPHOST.DB file. The problem is not specific to Mary's object record, however. It is specific to the block of records in the same location in the WPHOST.DB where Mary's object record is. A few other users' object records are also located in that damaged block in the WPHOST.DB file, which accounts for the other DB xx errors.

You can assume that there is minor structural damage to the WPHOST.DB file at this particular post office that's getting the error.

Now, suppose that when you discover this problem, it's 10 a.m. on a Tuesday. To rebuild a WPHOST.DB file, the POA must be down so that you have exclusive access to the WPHOST.DB file.

Rebuilding the WPHOST.DB file to fix this problem is out of the question. It's not system-critical, because users aren't complaining. You've just stumbled across a problem that you know must be resolved eventually. Suppose also that at your organization you have a very involved procedure to follow if ever you must have downtime during business hours. You want to avoid that procedure.

The system maintenance routine to run in this scenario is called Recover Database.

Recovering a WPHOST.DB file does not require exclusive access to it. You run a Recover Database routine and, after doing so, synchronize Mary's object. There should no longer be errors when you're synchronizing Mary's object.

The Recover Database routine quite often does not fix WPHOST.DB damage. In the preceding case, all it did was remove the damaged block of records. Your synchronization of Mary's object was required to complete the fix, because the recover routine just cut out the mushy bad part of the database, but it didn't replace the records that were lost. This is because the Recover Database routine only extracts information from the same WPHOST.DB file that you are trying to recover. The Recover Database routine is working with an information source that you already know to be questionable. If you can use the Recover Database routine to help you get along, that's great, but it should be considered a Band-Aid approach to get you past business hours. After hours, you should rebuild the WPHOST.DB file.

The ultimate fix to your problem with a WPHOST.DB file is almost always to rebuild it. The reason you would use the other options under System Maintenance is that they are less intrusive (you do not have to bring the POA down). You must have exclusive access to the WPHOST.DB file to rebuild it or replace it. The POA is generally the only entity with this file open. However, bringing down the POA in some organizations is a big deal, so you must try to limp along with a damaged WPHOST.DB file. The validate and recover options are really stop-gap measures until you can rebuild the WPHOST.DB file.

General Notes on Repairing Post Office Databases

The great thing about GroupWise architecture is that WPHOST.DB files can always be rebuilt, and with a guarantee against data loss. This is because everything written to the WPHOST.DB file is guaranteed to have been written to its owning domain's WPDOMAIN.DB file. When rebuilding a WPHOST.DB file, GroupWise administration is doing so from the perspective of the post office's owning domain.

The system maintenance routines are not the best way to resolve all GroupWise directory problems, however. For example, if a user's record is missing or incorrect from a post office's address book, synchronizing the user might be a simpler fix. Synchronizing a user's object, or any GroupWise object for that matter, repropagates that object to all GroupWise directory databases. This is far, far better than rebuilding every database on the system just to fix one record.


Fixing WPDOMAIN.DB Files

GroupWise WPDOMAIN.DB files should be approached differently than GroupWise WPHOST.DB files. Here are some concepts to keep in mind when repairing WPDOMAIN.DB files:

  • Secondary domain databases are always rebuilt from the perspective of the primary domain's WPDOMAIN.DB file.

  • The primary domain and its secondary domains might not always be in sync.

  • In some circumstances (although rarely), accessing the backup WPDOMAIN.DB file might be the best solution.

  • On some rare occasions, rebuilding a domain database might actually cause more problems than it fixes.

The best way to explore these concepts is through some scenarios.

For scenario #1, you are connected to the primary domain. You attempt to connect to DOMAINC, and when trying to do so, you get the error shown in Figure 22.3.

Figure 22.3. An error from a damaged WPDOMAIN.DB file

This error is telling you that your attempt to connect to the WPDOMAIN.DB for DOMAINC could not be changed because of a problem with the WPDOMAIN.DB for DOMAINC. On further investigation, you also see that the message transfer agent (MTA) for DOMAINC is not loaded. Things aren't looking good for DOMAINC's domain database.

It's a safe bet that DOMAINC's WPDOMAIN.DB file is corrupt beyond use. You can validate this theory by running a validate operation against DOMAINC. It will give some kind of an error, such as Error opening database. The WPDOMAIN.DB file needs to be replaced. The question then is should the WPDOMAIN.DB file be replaced from backup tape, or should it be rebuilt?

Theory tells us that everything that is in a secondary domain's WPDOMAIN.DB file is replicated up to the primary domain. If there is no reason to believe that this process of replication was impeded, don't hesitate to rebuild the DOMAINC WPDOMAIN.DB file. The WPDOMAIN.DB for DOMAINC is rebuilt from the WPDOMAIN.DB of the primary domain.

The decision to rebuild a WPDOMAIN.DB file rather than bringing it back from backup largely depends on your administration model. Suppose that you and one other person administer your GroupWise system. You both connect to the primary domain for administration purposes and connect to a secondary domain only occasionally. In this scenario, with an understanding of architecture, there is no reason to recover a secondary domain database from tape. The primary domain already knows about changes made to that secondary domain, because it proposed all the changes.

Now consider the following twist: Suppose that there is a damaged secondary domain that is in one of your field offices. A team in the field administers the secondary domain, and the team's wide area network (WAN) link to you is often unreliable. You and the domain administrator already concur that some of the changes made to the secondary domain might never have made it to the primary domain. If the field office has a recent backup of the WPDOMAIN.DB file, the team's copy might be the most accurate regarding the objects they own.

If they recover their WPDOMAIN.DB from backup tape, you have a new procedure to consider. You can assume that their WPDOMAIN.DB file is accurate, minus any changes that they made in their domain since the backup. The secondary domain administrator can worry about remaking those changes. As long as they didn't add, rename, or delete any users, it's not a big deal. Unfortunately, this secondary domain's WPDOMAIN.DB database is not going to be accurate regarding the changes made to the rest of the GroupWise system. To make matters more confusing, the primary domain database is not going to be accurate regarding objects owned by this out-of-sync secondary domain.

If you rebuild this secondary domain, the field office will lose some changes that the primary domain never knew about, unless, of course, you synchronize the primary domain with the secondary domain first. Here is the procedure for synchronizing the primary domain with the secondary domain:

1.
Highlight the secondary domain.

2.
Choose Tools, GroupWise Utilities, System Maintenance.

3.
Select Sync Primary with Secondary and click Run.

4.
After that procedure is complete, you can rebuild the secondary domain database.

Note

You will need file access to the secondary domain to go through this procedure. Because you are dealing with a field office with unstable WAN connections, consider bringing a copy of that office's domain database to your local site. When you are prompted for the path to the domain database to synchronize with, and later to rebuild, you can point to your local drive, or to a location on the network.

You had to synchronize the primary domain with the secondary domain so that the primary domain knew about the changes made to the secondary domain. When a secondary domain is rebuilt, it is done from the perspective of the primary domain. The secondary domain database on disk is ignored altogether. The Sync Primary with Secondary operation took care of this task for you, pushing up the secondary domain's information, on the objects it owns, to the primary domain. Then when the secondary domain is rebuilt just after the synchronize operation, the secondary domain will receive those objects back correctly. The secondary domain will also have all the correct information about the state of the GroupWise objects throughout the rest of the GroupWise system.

For scenario #2, the primary domain's WPDOMAIN.DB file is corrupted beyond repair. You know this because you cannot connect to the WPDOMAIN.DB in ConsoleOne, and the MTA for the primary domain will not load.

First of all, as a responsible network administrator, you should certainly have a backup of your primary domain. The question is whether restoring that backup is going to be the best thing to do. Typically, it is not the best solution.

The primary domain's WPDOMAIN.DB file on your backup will quite likely be outdated, especially if your system is administered from multiple secondary domain sites. Your best hope is a secondary domain that you feel is likely to be in sync with the primary domain. Recall the GroupWise architecture. The GroupWise primary domain broadcasts all changes made to all domains to every other domain. In theory, then, if everything is in sync, a secondary domain is just as well informed about the state of the GroupWise directory as the primary domain. You now need to generate a copy of the primary domain database from a secondary domain. Here is the procedure to generate a copy of the primary domain database from a secondary domain:

1.
Make sure that the primary domain's MTA is unloaded and that nothing is accessing the primary domain's WPDOMAIN.DB file.

2.
Rename the primary domain's WPDOMAIN.DB file to something that will indicate that this is the corrupt or bad database.

3.
Connect to the secondary domain that is most likely to be in sync with the primary domain.

4.
Highlight the primary domain.

5.
Choose Tools, GroupWise Utilities, System Maintenance.

6.
Select the Replace Primary with Secondary option, as shown in Figure 22.4.

Figure 22.4. The Replace Primary with Secondary option allows you to recover a lost primary database

You have now re-created the primary domain from the secondary domain. This solution is ideal because it does not require going to a backup solution.


Fixing GroupWise Directory Anomalies Without Rebuilds

There are other problems in the GroupWise directory that can't be readily fixed with system maintenance routines. In some cases, system maintenance routines could fix the problem, but you might want to avoid the downtime associated with rebuilding the databases.

We have seen cases in which an object is acting stubborn. You might need to slap it around a bit to get it to behave. Usually, these kinds of problems occur with user objects.

Note

Technically, user objects cannot act stubborn. We simply enjoy the anthropomorphism more than we should. The cases described here usually result when a single field in a record is out of sync, and perhaps damaged. By repeatedly attempting to rewrite that record, you can correct the field problem.

Following are the actions you can take with a user object to get it to behave. They are listed in the order of least drastic to most drastic measures. Most of the ideas here also apply to other GroupWise objects:

  • Synchronize the user.

  • Edit the user and make a minor change, click OK, and then remove the change.

  • Remove GroupWise-specific eDirectory attributes on the user.

First, when zeroing in on an object, be sure to connect to the domain that owns that object. This will speed up your troubleshooting significantly, because GroupWise administration snap-ins will write the change directly, instead of passing the change through multiple MTAs.

Synchronize the User

Following are the steps for synchronizing a user object:

1. | Highlight the user object.
2. | Choose Tools, GroupWise Utilities, Synchronize.
3. | Click Yes in the resulting dialog box.

This action rewrites the user's object to the WPDOMAIN.DB file, with much of the information coming from eDirectory. The synchronize operation also rebroadcasts the user's object record to all GroupWise directory databases. For a complete look at this process, refer to Chapter 7.

Edit the User

This is much like synchronizing the user object because it repropagates the record, but sometimes you'll have more success this way than by synchronizing the user. Follow these steps to edit the problematic user object:

1. | Highlight the user object.
2. | Right-click and select Properties.
3. | Make an unobtrusive change to the object. Don't change the object name, post office, or anything like that. Change a fax number or something similar.
4. | Click OK.

This action also repropagates the record to every domain and post office on the system. The difference here is that there is new record data involved, which might help solve the problem in some cases.

Remove GroupWise-Specific eDirectory Attributes

This procedure uncouples a user's GroupWise Directory Service object from its eDirectory counterpart. After performing this step on a user, you will see that the user's object in the GroupWise view has a white shirt. The user's object in the eDirectory browser view has a red shirt.

Note

You might need to exit ConsoleOne after performing this operation to see the shirt color difference.

Follow these steps:

1. | Highlight the user object.
2. | Choose Tools, GroupWise Utilities, GW/eDirectory Association, Disassociate GroupWise Attributes.

By uncoupling a user's GroupWise object from the eDirectory object, you eliminate one more factor. Sometimes your GroupWise Directory Services is perfectly healthy, but your eDirectory tree is having problems. Under these circumstances, you use the Disassociate GroupWise Attributes utility.

When you need to recouple a user's GroupWise object with the eDirectory object, do the following:

1. | Highlight the user object in the GroupWise view.
2. | Select Tools, GroupWise Utilities, GW/eDirectory Association, Associate Objects.
3. | Choose the Select Existing eDirectory Object option.
4. | Browse to the user's eDirectory object, and then click the OK button.

We often use these procedures when moving users. We disassociate the eDirectory object from the GroupWise object, move the user, and then reassociate the GroupWise object with its eDirectory counterpart.


How GroupWise Directory Changes and Objects Are Replicated

When you're troubleshooting the GroupWise directory, it's helpful to understand how changes replicate in the GroupWise directory. The following is an exhaustive discussion about how one object is replicated.

GroupWise object replication basically moves up from a secondary domain to the primary domain and from the primary domain to all other domains. Each domain is responsible for replicating objects to its respective post offices.

Objects and changes to objects or records in the GroupWise directory are replicated in the same manner.

Understanding a Scenario

Now, for the long explanation, consider the following scenario:

  • TKRATZER is the user.

  • DOMAINB is a secondary domain.

  • PO2 is the PO off of DOMAINB.

  • DOMAINA is the primary domain.

  • PO1 is the PO off of DOMAINA.

  • DOMAINC is a secondary domain.

  • DOMAIND is a secondary domain.

A GroupWise administrator is connected to DOMAINB. The administrator creates TKRATZER. TKRATZER is added to PO2. Here's what happens:

  1. TKRATZER's record is committed to the WPDOMAIN.DB file for DOMAINB by ConsoleOne.

  2. TKRATZER's record is broadcast to PO2 by DOMAINB's MTA.

  3. TKRATZER's record is broadcast to DOMAINA's MTA by DOMAINB's MTA.

  4. PO2's POA accepts TKRATZER's record and commits it to PO2's WPHOST.DB file.

  5. DOMAINA's MTA accepts TKRATZER's record and commits it to DOMAINA's WPDOMAIN.DB file.

  6. DOMAINA's MTA broadcasts TKRATZER's record to its post office PO1.

  7. PO1's POA accepts TKRATZER's record and commits it to PO1's WPHOST.DB file.

  8. DOMAINA broadcasts TKRATZER's record to all other domains in the system besides DOMAINB. This includes DOMAINC and DOMAIND.

  9. DOMAINC accepts the broadcast of TKRATZER and does everything that DOMAINA did with the object, except it does not broadcast TKRATZER to anyone outside its domain. That is DOMAINA's job, because DOMAINA is the primary domain.

  10. DOMAIND does exactly what DOMAINC does.

This completes the process and the user is now added.

Understanding the File Flow and Logic

The following is a very detailed scenario that illustrates the file flow and the logic of a user object creation. The names of the files are relevant only to the operation that took place on a test system. The names of the files created on your system will be different:

  • TKRATZER is the user.

  • DOMAINB is the secondary domain.

  • PO2 is the PO off of DOMAINB.

  • DOMAINA is the primary domain.

  • PO1 is the PO off of DOMAINA.

  • DOMAINC is the secondary domain.

  • DOMAIND is the secondary domain.

For this scenario, communication between all domains and post offices is via TCP/IP. Here's what happens:

  1. Connected to DOMAINB, the administrator creates a user object, TKRATZER, under DOMAINB, PO2.

  2. The change is committed to the DOMAINB WPDOMAIN.DB file.

  3. Two files are created in the DOMAINB\WPCSIN\2 directory:

    File one is called A7D93EDD.000.

    File two is called A7D93EDD.001.

  4. File one is picked up by DOMAINB's MTA and copied to the GWINPROG\2 directory using a router thread (RTR), and is moved to the input queue for the MTP portion of the MTA.

    DOMAINB's MTA log reports the following:

    RTR: DOMAINB: 00000800: Routing
comm3/sys:\domainb\mslocal\gwinprog\2\00000800

RTR: DOMAINB: 00000800: Originator: DOMAINB.Domain
Message Server [ADS]
RTR: DOMAINB: 00000800 Priority 10 :0:0 : Transfer to DOMAINA

RTR: DOMAINB: 00000800: Message queued:
 comm3/sys:\domainb\mslocal\mshold\dom3859\2\00000800.001

  5. The MTP portion of the DOMAINB MTA finds the file and transmits it to DOMAINA, the primary domain. Note that the name of the thread is DOMAINA-IPS0 but that this is a thread created by DOMAINB's MTA.

    DOMAINB's MTA log reports the following:

    MTP: DOMAINA-ipS0: Connection established. 151.155.106.66
MTP: DOMAINA-ipS0: Transmitting file
comm3/sys:\domainb\mslocal\mshold\dom3859\2\00000800.001

  6. A new copy of the message is also made for PO2, and queued up to the MTP process of the DOMAINB MTA.

    DOMAINB's MTA log reports the following:

    RTR: DOMAINB: 00000801: Routing
comm3/sys:\domainb\mslocal\gwinprog\2\00000801

RTR: DOMAINB: 00000801: Originator: DOMAINB.Domain
Message Server [ADS]

RTR: DOMAINB: 00000801 Priority 10 :0:0 :
Transfer to DOMAINB.PO2:ADS

RTR: DOMAINB: 00000801: Message queued:
comm3/sys:\domainb\mslocal\mshold\po23a0e\2\00000801.001

  7. DOMAINB's MTA transmits the file to PO2 and reports the following in the log:

    MTP: PO2-ipS0: Transmitting file
comm3/sys:\domainb\mslocal\mshold\po23a0e\2\00000801.001

  8. PO2's POA MTP process reports the following about receiving the message from the domain:

    MTP: Receiver thread started: 1 running
MTP: DOMAINB: Attention packet received
MTP: DOMAINB: Accepting connection
MTP: DOMAINB: Returning acknowledge (0)
MTP: DOMAINB: File transfer request received

MTP: DOMAINB: Received file: COMM3\SYS:/DOMAINB/PO2\wpcsout\
ofs\2\A7d950d6

MTP: DOMAINB: Returning acknowledge (3)

Processing a7d950d6.000
Domain Message Server.DOMAINB
Admin message processed: OK
MTP: DOMAINB: File transfer request received

MTP: DOMAINB: Received file: COMM3\SYS:/DOMAINB/PO2\wpcsout\
ofs\2\A7d950d8
MTP: DOMAINB: Returning acknowledge (3)
Processing a7d950d8.000
Domain Message Server.DOMAINB
Admin message processed: OK

  9. The POA places the administration files in the WPCSOUT\ADS\2 directory. They are called 37D950D6.000 and 37D950D8.000.

  10. The delivery thread on the POA then tickles the admin thread of the POA (this does not show in the logthe event takes place in the POA stack, behind the scenes).

    The admin thread reports the following:

    ADM: Completed: Update object in Post Office
User DOMAINB.PO2.TKRATZER (Administrator: (WWW_TREE_1)
tkratzer.WWW, Domain: DOMAINB)
ADM: Completed: Update object in Post Office - MTA DOMAINB
(Administrator: (WWW) tkratzer.WWW, Domain: DOMAINB)

    Tip

    The GroupWise POA reports who made the change to the object. However, it is sometimes incorrect. The reason for this is that sometimes the GroupWise snap-ins do not update the Last Modified By field, so a transaction will report in the log of the POA as being performed by ADMIN-A when the change was really performed by ADMIN-B.

  11. Meanwhile, DOMAINA's MTA is receiving the file from DOMAINB's MTA.

    DOMAINA's MTA log reports the following:

    MTP: DOMAINB: Received file:
comm3/sys:\domaina\mslocal\gwinprog\2\00000801

RTR: DOMAINA: 00000801: Routing
comm3/sys:\domaina\mslocal\gwinprog\2\00000801

  12. DOMAINA's MTA identifies the message as an administrative message and queues the message up to its admin thread in the WPCSOUT\ADS\2 directory.

    DOMAINA's MTA log reports the following:

    RTR: DOMAINA: 00000801: Originator: DOMAINB.Domain
Message Server [ADS]

RTR: DOMAINA: 00000801 Priority 10 :0:0 :
Transfer to DOMAINA.Domain Message Server:ADS

RTR: DOMAINA: 00000801: Message queued:
comm3/sys:\domaina\wpcsout\ads\2\B7d94d48.00!

  13. DOMAINA's MTA tickles the admin thread, and the admin thread reports the following:

    ADM: Completed: Update replica User DOMAINB.PO2.TKRATZER

  14. DOMAINA's MTA then queues the message up to its post office, PO1.

    It does this in the exact manner in which the DOMAINB MTA queued up the change to PO2.

  15. DOMAINA's MTA then broadcasts the administration message to both DOMAINC and DOMAIND in the same manner that DOMAINB broadcasts the administration message up to DOMAINA.

  16. DOMAINC and DOMAIND's MTAs broadcast the administration message to their post offices, just as DOMAINB broadcasts its administration message to PO2.

A very simple operation in GroupWise administration becomes a file that must be replicated to all other GroupWise directory databases.


Best Practices for Working with the GroupWise Directory

For a large GroupWise system, here are some good rules to follow:

  • If you perform a large number of operations, such as grafting or modifying multiple users on a domain, GroupWise administrator should be connected to the domain that owns the objects being modified. If you do not do this, you will generate about 50% more administration traffic between domains than you need to. We therefore suggest connecting to the proper owning domain and not doing administration while connected to the primary domain.

  • If your system has a lot of administration messages flowing through it, implement the 2nd Mail Priority Router on the primary domain MTA. To do this, edit the MTA object, go to the Agents Settings page, and check the box named 2nd High Priority Router. This will provide an additional thread for processing admin messages, making bottlenecks at the MTA less likely.

  • Design your GroupWise system so that your primary domain is only doing administrative work. If the primary domain is housing the GroupWise Internet Agent (GWIA), or is a routing hub for all other domains, it might not be efficient enough in servicing GroupWise administration changes. It is ideal to see to it that the primary domain does not own any post offices.

These best practices should be more closely adhered to in systems with a few thousand or more users.


Bulletproofing the GroupWise Directory

The following practice is not widespread, but it is definitely worth mentioning. This idea came about when a customer's primary domain WPDOMAIN.DB file went bad. The idea of going to backup just wasn't all that pleasing because of all the changes made in the system since the customer performed the last backup. The customer needed to re-create the primary domain from a secondary domain.

The system maintenance feature, Replace Primary with Secondary, is a lifesaver, but it raises an important question: How do you guarantee the integrity of a secondary domain database, ensuring that you'll have a fail-safe backup if your primary domain goes bad?

Here is a way to do just that:

1. | Create a special-purpose secondary domain, for example, a domain called BACKUP-PRIMARY-DOMAIN. Host it somewhere in your network, in close proximity to the primary domain. Ideally, it should be on a separate server, but on the same LAN segment as the server hosting the primary domain. You need to disable others from connecting to this WPDOMAIN.DB file with ConsoleOne. You do this by tricking all domains into thinking that this secondary domain is at a different UNC path than it really is. Steps 2 and 3 help you do this.
2. | While connected to the primary domain, change the UNC path to the secondary domain BACKUP-PRIMARY-DOMAIN to make it invalid.
3. | Restrict eDirectory object rights to this domain so that only a few people have such rights.
4. | Establish MTA-to-MTA links so that only the primary domain can speak to this domain.
5. | Establish a TCP/IP link between the two domains.

Tip

To connect to the BACKUP-PRIMARY-DOMAIN domain, you need to choose Tools, GroupWise System Operations, Select Domain, and then manually attach to the WPDOMAIN.DB for this domain. Right-clicking and choosing Connect won't work because the UNC path to the BACKUP-PRIMARY-DOMAIN is incorrect.

The system now has, in effect, a fully replicated version of the primary domain database, which is only about one minute out of sync with the primary domain. Should the primary domain database become irretrievably corrupted (in the case of a major disk failure, for instance), you have a secondary domain database that is the best possible candidate for use in a Replace Primary with Secondary operation. Just connect manually to WPDOMAIN.DB for the BACKUP-PRIMARY-DOMAIN and then perform the Replace Primary with Secondary system maintenance routine that was outlined previously in this chapter.


Understanding the Administration System

The administration of the GroupWise system goes hand in hand with the GroupWise directory. The administration system of GroupWise consists of two separates sets of software components:

  • GroupWise administrator snap-ins to ConsoleOne

  • The admin threads of the MTA and the POA

The GroupWise Snap-Ins

The GroupWise administration snap-ins are often misunderstood. Administrators are quite often cognizant of the version of the GroupWise client, or the version of the GroupWise agents. There is often little emphasis placed on determining the version of GroupWise administration.

The version of administration is especially important when you have implemented a patch or a new version of GroupWise, and you really want to leverage the new fixes or features in that patch or new version. As discussed in Chapter 7, to determine the version of GroupWise administration you are using, do the following:

1.
Load ConsoleOne.

2.
Choose Help, About Snapins. You should see the screen shown in Figure 22.5.

Figure 22.5. About Snapins in ConsoleOne

3.
Click a snap-in to see its version information.

Is this the version you want to be running? Is this version of the GroupWise snap-ins on every file server or workstation where ConsoleOne is running?

Many of Novell's customers have a huge GroupWise installation that is managed by several administrators. It is important that everyone who runs ConsoleOne is using the latest GroupWise snap-ins, or at least the latest ones that have been approved for your organization. If this is not the case, someone might be causing problems in the GroupWise systemproblems due to bugs that have been addressed in a later patch of the GroupWise administrator snap-ins.

Tip

GroupWise Administrator allows you to restrict which versions of snap-ins are allowed to connect to a GroupWise domain. This can be useful for preventing older snap-ins from accessing a WPDOMAIN.DB file and performing administration tasks. Define this setting from Tools, GroupWise System Operations, Admin Lockout Settings. From there, you can lock out older snap-ins.

Note

Only the 6.5 and later snap-ins will honor the lockout setting. GroupWise 6.x and older snap-ins do not honor this setting; they can access the domain database even when this setting is in effect through the 6.5.1 snap-ins.

Understanding the GroupWise Admin Thread

The admin thread is just a subprocess of the MTA and the POA. In the MTA and POA log files when the admin thread runs, it is logged as ADM. This chapter discussed this earlier, and this concept is also discussed in Chapter 8, "Configuring the Post Office Agent," and Chapter 9, "Configuring the Message Transfer Agent."

The admin thread on an MTA or a POA is responsible for updating its respective directory database. This admin thread has two input queues:

  • The ADS directory queue: The first input queue for the admin thread is the WPCSOUT\ADS\2 directory off of a post office or domain. The admin thread comes to life every minute. For example, when a POA's admin thread discovers a file in the PO\WPCSOUT\ADS\2 directory, it makes a change in the WPHOST.DB file. If a domain MTA's admin thread discovers a file in the WPCSOUT\ADS\2 directory, it makes the appropriate change to the WPDOMAIN.DB file.

  • The tickle queue: The admin thread will also come to life when it gets a tickle from the POA or MTA that owns the thread. In GroupWise 6.5 or higher, although the admin thread comes to life every minute, when an MTA or a POA gets an administration message via a TCP/IP connection, it queues the message up to the admin thread by a routine in memory. At the GroupWise domain/MTA level, quite often administration files do not go into the WPCSOUT\ADS\2 directory. They are instead handed off to the admin thread while they are in the MSLOCAL\GWINPROG directory.


Summary

There are various ways to fix a GroupWise directory problem. You need to determine what the problem is and determine the most expedient solution. With an understanding of the architecture, you will be better able to troubleshoot these problems and find the best solutions.

Always remember that the GroupWise synchronization process is complex, and that several GroupWise agents might need to be involved to replicate an object. Make sure that every agent is communicating correctly before going further.


Chapter 23. Troubleshooting GroupWise

Every application, or suite of applications, has its own particular set of error messages; GroupWise is no exception. As you administer your GroupWise system, you will inevitably see some errors. This chapter discusses the logic behind the errors and gives you some procedures to help you quickly arrive at the root of the problem plaguing you.

Note

For information specific to troubleshooting GroupWise message flow, refer to Chapter 20, "Troubleshooting Message Flow."


The Five Most Common GroupWise Errors

The following sections include a quick reference to the five most common errors seen in GroupWise, what they typically mean, and the actions to take to solve them.

D107Record Not Found

Description: This error means that one record has a reference to a second record, and the second record is not found. This is typically considered a content-related problem in a message store database (rather than a structural problem). This typically happens when a pointer record in a user's database (USER xxx.DB) points to a record in a message database that no longer exists. Another possibility is that a master record in a message database (MSG xxx.DB) points to another record in the message database that does not exist.

Action: In the case of a message store database, usually a contents check of the database resolves the problem. The trick is determining which database to check. Chapter 20, "Troubleshooting Message Flow," explains where data is kept based on the message type or who sent it. If you have questions as to which database to check, read Chapter 20.

Tip

You can run a contents check on a specific MSG xxx.DB file. To do so, run the standalone GWCHECK and enter the name of the MSG xxx.DB file in the User/Resource field. See Figure 23.1 for an example.

Figure 23.1. Running GWCHECK on an MSGxxx.DB file

[View full size image]

8209Path to File Not Found

Description: In this case, GroupWise is trying to access a file and it cannot. This generally means that either the path you specified is incorrect, or the GroupWise software cannot reach the path because of assigned rights. If the software can reach the path, it cannot find the file it expects to find there.

Action: Indicate a correct path, put the file in place that GroupWise is looking for, and make sure that the GroupWise process has rights to the location indicated.

C05DDependent Store Does Not Exist on Disk

Description: Every database in the GroupWise message store is registered in the NGWGUARD.DB file. This error means that a database is registered in the NGWGUARD.DB file, but it is not physically in the location where the NGWGUARD.DB says the file should be. In the case of an NGWGUARD.DB on a post office, all USER xxx.DB files should be in the post office\OFUSER directory. If the post office agent (POA) reports a C05D error on a file by the name of USER123.DB, this means that the NGWGUARD.DB file reports that the file is in the post office\OFUSER directory, but it cannot find the file there. If the POA complains of a C05D error on an MSG xxx.DB file, that means it cannot find the file in the post office\OFMSG directory.

The GroupWise message store can also exist in a GroupWise archive, a GroupWise caching mailbox, or a GroupWise remote mailbox.

Action: Although the cause is easily stated, the action is not so easy to spell out. The solution varies based on the conditions in which you have the problem. This is best illustrated with a few scenarios.

Scenario 1Issue: UserA moved from PO1 to PO2. However, the user's mail did not move to PO2. The administrator moved UserA back to PO1, fixed UserA's mailbox, and then attempted to move UserA to PO2. The POA at PO2 gives the error C05D with reference to UserA's USER xxx.DB file.

Scenario 1Explanation: On PO2, a new USER xxx.DB file was created for UserA the first time UserA moved there. UserA might have even received a couple of messages from USER xxx.DB from the PO2 post office. When UserA was moved back to PO1, PO2 sent the few new message items to PO1, deleted the USER xxx.DB file from the post office, and unregistered it in the NGWGUARD.DB file. Everything is correct, but the POA has an old image of the NGWGUARD.DB cached in memory, and it hasn't reread the NGWGUARD.DB file. As strange as it might seem, the POA is the same one that deleted the reference to the USER xxx.DB file in the NGWGUARD.DB, but it doesn't even acknowledge that.

Scenario 1Action: You need to bring the POA down and then back up so that it rereads the NGWGUARD.DB file. Then you must attempt to move UserA again. See Chapter 13, "Moving Users," for more guidance on trying to move a user when a move fails the first time.

Scenario 2Issue: A user is attempting to archive a message, and receives a C05D error. You look in the Archive directory and there is only a NGWGUARD.DB and a MSG.DB file (there's no USER.DB file).

Scenario 2Explanation: In the Archive directory (the OF XXX ARC directory, in which the XXX is the user's three-character FID), there is an NGWGUARD.DB file. This file is complaining that the USER.DB or the MSG.DB file in the OF XXX ARC directory is not registered in the NGWGUARD.DB file.

Scenario 2Action: Follow these steps:

1.
Exit the GroupWise client as the user with the problem.

2.
Go to the archive OF xxx ARC directory.

3.
Rename the NGWGUARD.DB to NGWGUARD.BAD.

4.
Rename the MSG.DB to MSG.GOOD (if there is a MSG.DB).

5.
Go into GroupWise as the user.

6.
Have the user send one simple message to and from his or her email address.

7.
Archive that one message.

8.
Exit GroupWise.

9.
Go to the archive OF xxx ARC directory.

10.
Delete the newly created MSG.DB file.

11.
Rename the MSG.GOOD file to MSG.DB.

12.
Run the standalone GWCHECK on the user's archive, as shown in Figure 23.2. Perform the Re-create User Database action.

Figure 23.2. Running GWCHECK on a user's archive

[View full size image]

After doing this, all the user's messages that were recovered from the MSG.DB file will have their pointers added to the USER.DB file. The messages will be placed in the Cabinet.

C067Store Number Is Invalid

Description: This error means that a database in the GroupWise message store is physically located in the message store, but is not registered in the NGWGUARD.DB file. This error might be thought of as the reverse of the C05D error. This is generally evidence of the fact that the NGWGUARD.DB file is damaged, and therefore lost its reference to a database, or the file was placed back into the message store area manually, but was not reregistered in the NGWGUARD.DB file.

Action: Once again, the action you take varies based on the scenario. Here's an example of one scenario:

Issue: The user TKRATZER tries to log into his account. He cannot log in; he gets a C067 error when trying to do so. The POA also reports a C067 error in its log when user TKRATZER tries to log in.

Explanation: TKRATZER's user database file (USERTAY.DB) is not registered in the NGWGUARD.DB file. It does exist in the post office\OFUSER directory. The NGWGUARD.DB file probably sustained some damage, and as a result the Registry for USERTAY.DB was lost from the NGWGUARD.DB.

Action: Follow these steps:

1. | Go to the post office\OFUSER directory of the post office where TKRATZER resides.
2. | Rename the file USERTAY.DB to USERTAY.GOOD.
3. | Have the user TKRATZER log in, and then have user TKRATZER log out. Doing so will create a new USERTAY.DB file that is now registered in the NGWGUARD.DB file.
4. | Rename the new USERTAY.DB file to USERTAY.NEW. (You might have to wait for several minutes to be able to do this because the POA has this file cached. Otherwise, you can bring the POA down and back up.)
5. | Rename the USERTAY.GOOD file to USERTAY.DB.

The user TKRATZER should be able to log in now, without getting the C067 error.

C022Database Damage

Description: The database is damagedstructurally. This means that when GroupWise is attempting to read the database, it isn't finding the layout of the database to be standard. GroupWise cannot proceed in accessing the database, because it cannot guarantee consistent results. Let's tie this to an analogy: Imagine you come into your bedroom in the dark and your other half has moved the furniture around. There's no guarantee you aren't going to stub your toe if you proceed.

Action: The database needs to be rebuilt. If the database is a GroupWise domain or post office database, it must be rebuilt from the System Maintenance utility. If it's a message store database, it must be structurally rebuilt from GWCHECK or from Mailbox/Library Maintenance.


Using the Scientific Method

Before this discussion begins, it might not be a bad idea to review the scientific method. Most high school science students learn that this method has four important steps:

1. | Observe.
2. | Hypothesize.
3. | Predict based on the hypothesis.
4. | Test the hypothesis.

The scientific method provides you with a very effective plan for troubleshooting. Too often, administrators are so wound up in their search for a solution that they shoot from the hip, hoping perhaps to stumble on the answer. Sometimes this works.

Sometimes, though, you'll encounter a real stumper of a problem, and the standard bag of tricks isn't going to help. This is when the scientific method can really help.

The most important part of the scientific method is the observation phase. For the scientific method to work well, you need to have a good set of observation tools. You must carefully observe the conditions that are generating the errors in order to make meaningful predictions. The following sections cover some of the tools that allow you to take a close look at the components in your GroupWise system.

Windows Workstations/Servers

The following tools are for Windows-based systems:

  • NETSTAT: This utility tells you what ports the local host is listening to, and what ports it's talking to on remote hosts, and what sockets the local host is listening on. Typically you will use the command with the following syntax: netstat -na.

  • IPCONFIG: This command-line version of the WINIPCFG utility tells you vital information about the IP configuration of the local machine.

  • PING: The PING tool allows you to send small packets via TCP/IP to any host on the network or internetwork (or Internet, for that matter). If you can't connect to the POA, you should see whether you can ping it.

  • TRACERT: The tracert command is used to determine how a network packet is being sent and received and the number of hops required for that packet to get to its destination.

  • TELNET: The TELNET tool allows you to open a TCP/IP connection on any port, to any host on the network or Internet. If you can't connect to the POA with the GroupWise client, perhaps you should see whether you can connect to port 1677 (the client/server port) of the POA using the TELNET tool.

  • REGMON: This utility tells you what calls are being made to the Registry. Although it takes some practice to use this tool well, it's great for determining which Registry entries are causing a problem. You can obtain Registry Monitor (REGMON) from www.sysinternals.com.

  • FILEMON: This utility is similar to REGMON, except that it tells you every file on a Windows platform that is accessed. You can obtain this utility from www.sysinternals.com as well.

NetWare Servers

These tools will work on your NetWare-based systems:

  • PING.NLM: This is the NetWare version of the PING tool. It allows you to choose the packet size, and will even keep some simple statistical tallies as you ping hosts from the server console.

  • GWIP.NLM: This tool is a little better than a ping, and almost as good as a TELNET. Because there is no true TELNET tool for a NetWare server, GWIP.NLM is an excellent addition to your troubleshooting toolkit. You can download it from www.support.novell.com. Search for GWIP.NLM in the knowledgebase.

  • IPTRACE.NLM: This tool is the equivalent of the TRACERT tool on the Windows platform. It allows you to trace the IP route from a NetWare server.

  • TCPCON.NLM: Load TCPCON and then go to Protocol Information, TCP, TCP Connections. You can determine whether a GroupWise agent is actually listening on a port.

  • MONITOR.NLM: Here you can get an idea of how your system resources are faring. Look at things such as the Disk Cache Utilization and LRU Sitting time. (This is the menu tree on a NetWare 6.0 server.) This value should be well above 15 minutes. You can also determine which server processes are taking up the most CPU time. This is a very powerful and complex tool.

  • CONFIG: This command-line utility tells you vital information about the IP configuration of the NetWare server.

Linux Servers/Workstations

These tools will work on your Linux-based systems:

Almost all Linux-based commands have a help screen and a man page. To get more help with a command, use the following syntax: command -help or command -h or command --h. To see the man page for a command, use the following syntax: man command. Helpful utilities are listed here:

  • ping: This is the Linux version of the PING tool. It allows you to choose the packet size, and will even keep some simple statistical tallies as you ping hosts from a terminal session.

  • telnet: This tool allows you to open a TCP/IP connection on any port, to any host on the network or Internet. If you can't connect to the POA with the GroupWise client, perhaps you should see whether you can connect to port 1677 (the client/server port) of the POA using the telnet tool.

  • traceroute: The traceroute command is used to determine how a network packet is being sent and received and the number of hops required for that packet to get to its destination. Use the command traceroute h or man traceroute for more documentation on ping.

  • netstat: This utility tells you what ports the local host is listening to, and what ports it's talking to on remote hosts, and what sockets the local host is listening on. Typically, you will use the command with the following syntax: netstat na | grep the port you are looking for.

  • top: Here you can get an idea of how your system resources are faring.

  • ifconfig: This command-line utility tells you vital information about the IP configuration of the Linux host.

  • lsof: Thiscommand-line utility lists the open files on the Linux server. Because in Linux everything is represented as files and folders, you can actually search for ports with the lsof command. An example of looking for the ports that are open is the command lsof | grep LISTEN.


GroupWise Error Codes

Now that you have some observation tools in your scientific-method toolbox, you need to know what the error codes mean. Most problems reported by GroupWise components are accompanied by some kind of a four-character error code, such as 8201 or C05D. These codes map to certain kinds of problems. Rather than memorizing the individual mappings, however, it is useful to learn the families, or classes, of error codes.

82 xx Errors

The 82 xx class of errors indicates some sort of file access or file I/O problem. Perhaps the POA is trying to access a database at a given path, but the database is not there (8209, path not found). A possibility is that file-system rights have not been granted to a message transfer agent (MTA) that is attempting to poll a remote post office (8201, access denied).

89 xx Errors

You will generally see 89 xx errors in conjunction with TCP/IP communication problems. For example, if a POA goes down, the GroupWise client will report an 8908 error. If the MTA times out on a communication with a POA, it might report an 8912 or an 8913 error. The 89 xx error suite also includes many errors outside of the realm of TCP/IP communications, but the non-TCP/IP errors do not crop up as often.

C xxx Errors

The C xxx errors typically point to database structural integrity problems. For example, a user receives C022 errors when creating any item in GroupWise. The error means that database integrity has been compromised. The C04F error indicates that the database checksum did not add up correctly. In either case, you know from the error class that a GroupWise store file has structural damage.

There are two C xxx-class errors that are a little bit different: C05D and C067. Both of these errors indicate structural damage to the information/message store, rather than just to one store file. This means that one or more store files are not correctly registered in the GroupWise guardian database. C05D indicates a registered store file that could not be found. C067 indicates that a store file could not be created, because an unregistered version exists on disk.

D xxx Errors

The D xxx class of errors points to database content problems. The problem might be a missing record, which will return a D107 error. A missing user record (when the POA tries to deliver to a user who does not exist in the address book) might flag a D101 error. The problem might not be that a record is missing, though. It might simply be that the data does not match what the GroupWise component was expecting to see, such as when the entered password does not match the one required (D109, access denied).

E xxx Errors

The E xxx class of errors changes the rules a bit. Instead of mapping to a database problem or an I/O problem, E-class error messages indicate that the problem was found while using a document-management feature. The error state might actually indicate a normal situation, such as when a user tries to access a document that he or she has not been given rights to (E51B). It might also indicate a content problem with the document-management databases. A missing document record will return an E811 error.

Using the Error Classes

If you know what each error class means, you will still be missing an important piece of the puzzle. Most GroupWise errors tell you what kind of a problem was encountered but do not tell you which component had the problem. For instance, if the GroupWise client is encountering structural problems working with the GroupWise archive, it will probably report a C022 or C04F error. Those are the same errors the POA would use to report problems with a message database in the post office directory. The same error can be reported by two different components, and it can be caused by a problem in any of several areas.

The only way you can know which component has the problem is to apply some of the architectural information available in the rest of the book. Here are some questions you can ask yourself that might help:

  • Which component reports the error? For instance, if the POA reports a C022, you will see the error in the log. Check the log for any other information about the problem. Generally, the POA will report which database it's having a problem with.

  • Which components do not report the error? Suppose the client reports an error, but the POA does not. This narrows the problem quite a bit. The databases that a client has exclusive access to that the POA does not have access to are the archive databases and the caching mode and remote databases.

  • Which pieces are touched by the component(s) that report(s) the error? If you know, for instance, that the client reports an error, but the POA does not, you need to determine which pieces the client touches that the POA does not. In client/server access mode, the problem likely is the GroupWise archive. In direct access mode, the problem might be the master mailbox or the archive.

The Complete List of GroupWise Error Messages

As of this writing, Novell has not published a complete list of the error codes used by all GroupWise components. Fortunately, the more common errors have been well documented, and appear online at Novell's support connection Web site.

The Novell Support Connection

When you see an error message, you can look it up in the knowledgebase at http://support.novell.com. The odds are good that you are not the first person to see this message. This method is helpful for looking up messages one at a time, as you encounter them.

The Novell Online GroupWise Documentation

You can access the GroupWise online documentation to get a comprehensive list of most of the error codes in GroupWise. This site can be very helpful in identifying the various error messages' meanings. It is found at http://www.novell.com/documentation under the Troubleshooting Guides section.

GroupWise Magazine

The GroupWise magazine is a great tool for administrators and users alike. We also write for this magazine. To access this magazine, go to one of the following locations:

www.gwmag.com
www.novell.com/coolsolutions/gwmag/

Use the Support Connection

Although the troubleshooting advice in this chapter is sound, here's the best advice of all: Don't troubleshoot if you don't have to!

Novell has a world-class support site. Use the knowledgebase at http://support.novell.com before you begin racking your brain. In most cases, the exact set of conditions you are seeing has already been documented by Novell Technical Services, and one or more ready-made solutions await you. Why reinvent the wheel?


Using Three-Step Mailbox Troubleshooting

On a large system, you might see mailbox-related errors often enough that you don't want to take the time to actually troubleshoot each one. Well, a GroupWise administrator we worked with passed along a gem. This administrator takes a standard approach to every problem he gets with a user mailbox, no matter what the error is. This approach fixes about 80% of the problems right off the bat.

The nice thing about this approach is that the operations you will be performing are not invasive or destructive. These actions can be performed on a healthy mailbox with no ill effects. This means that almost no matter what the problem, you can take these steps safely.

You could use this procedure to solve a myriad of problems, such as these:

  • One user receives errors when trying to send new messages.

  • Everybody receives errors when trying to send a message to one particular user.

  • A user reports that messages he or she has read are showing up as unread.

This list could go on and on. Suffice it to say that if you think the problem is related in any way to the GroupWise message/information store, this procedure is a good place to start.

These steps must be completed in order:

1. | Synchronize the user.
2. | Run a structural rebuild on the user database using GWCHECK. (Server-based or standalonesee Chapter 17, "Maintaining the GroupWise System," for more details.)
3. | Run an analyze/fix of the contents of the user database (do not include the message database).

The logic behind these steps is simple. First, make sure that the user object you want to work on is correctly represented in the post office database. The synchronize operation takes care of that.

Second, make sure that the user database for this user is structurally clean, with no damaged blocks or records for you to choke on. The structural rebuild operation takes care of this.

Finally, you want to make sure that all records in the user database correctly point to records elsewhere in the information store. The analyze/fix operation does this for you.

The rest of this section walks through each of these operations in turn.

Synchronize the User

The synchronize function, covered in Chapter 7, "GroupWise Utilities and Diagnostics," broadcasts a user's GroupWise object to the entire GroupWise system. Synchronizing is a fairly quick operation. To synchronize a user, do the following:

1. | Load ConsoleOne.
2. | Highlight the user in GroupWise view or in eDirectory browser view.
3. | Choose Tools, GroupWise Utilities, Synchronize.

Structurally Rebuild the User's Database

Now that the user object has been synchronized, you are ready to issue a structural rebuild on that user's database. To accomplish this task, follow these steps:

1. | Load ConsoleOne.
2. | Highlight the user in GroupWise view or in eDirectory browser view.
3. | Choose Tools, GroupWise Utilities, Mailbox/Library Maintenance.
4. | In the Action drop-down list, select Structural Rebuild.
5. | Under the Databases tab, select the User check box, making sure that the Message option is unchecked.

Note

Administrators are sometimes reluctant to do a structural rebuild on a user. They have a mistaken notion that a structural rebuild of a user database is a drastic, potentially destructive operation. It is not! A structural rebuild does not throw messages out of the folders or into the root of the cabinet. Don't mistake a structural rebuild with the process of re-creating the user database, which is an entirely different function. (Re-creating a user database will throw messages out of folders.)

Analyze/Fix and Repair the Contents of the User Database

When the POA analyzes the contents of a user database, it validates all the pointers in the database. The contents analysis also cleans up a user's personal address book. Here are the steps for running this operation:

1. | In ConsoleOne, highlight the user in GroupWise view or in eDirectory browser view.
2. | Choose Tools, GroupWise Utilities, Mailbox/Library Maintenance.
3. | From the Action drop-down list, select Analyze/Fix Databases.
4. | Select the Contents and Fix Problems check boxes, as well as the User check box under the Databases tab, making sure to uncheck all other check boxes.


Determining Problem Specificity

The steps in the preceding section could have taken care of a mailbox problem. If they did not, some very simple troubleshooting begins. Here is a systematic approach.

Determining Whether the Problem Is Machine-Specific

As the administrator, can you duplicate the problem from your own machine? Log in to the network as yourself and access the problem user's account by using the /@u-? switch. For troubleshooting purposes, have an extra GroupWise icon on your desktop. The icon should have a /@u-? switch after the GRPWISE.EXE. See Figure 23.3 for an example of this.

Figure 23.3. An extra GroupWise troubleshooting program shortcut

You must have GroupWise notify and the other GroupWise client software, such as the address book, unloaded in order to get into someone else's GroupWise account (the client suite can connect to only one account at a time). You will also need the user's password in order to enter the user's mailbox when using the /@u-? switch.

Troubleshooting Machine-Specific Problems

Suppose, however, that you can't duplicate the problem from your own machine. If this is the case, it's likely a machine-specific problem. Perhaps something has corrupted the GroupWise installation. At this point, we don't have a nice, numbered list of steps, but we do have a few suggestions, covered in the following sections.

Uninstall/Reinstall

One option is to try uninstalling and reinstalling a few components:

  • Uninstall and then reinstall GroupWise.

  • Reinstall Windows messaging. Windows messaging can be reinstalled from the GroupWise software distribution directory by running WMS.EXE from the CLIENT\WIN32\WMS\xx directory in your software distribution directory. For Windows 98 and ME, run WMS from the 95 directory. For Windows NT/2000 and XP, run WMS.EXE from the NT directory.

  • Uninstall Windows messaging. This can be hard to do on some machines because, although Windows messaging is installed, there's no uninstall option in the Windows Control Panel. This might sound funny, but you might have to run WMS.EXE to install Windows messaging before the Windows Control Panel will allow you to uninstall it.

  • Change Windows messaging profile information. Delete the GroupWise profiles and then add them back in. The Windows messaging profile information is typically in the Control Panel under the Mail or Mail/Fax option. Sometimes this option isn't available. If you can load the GroupWise client, go to the address book and choose File, Services.

Troubleshooting TCP/IP from the Workstation

Perhaps the problem looks like a TCP/IP communication problem between the client and the POA (89 xx-class errors). If so, try these steps:

1.
Ping the server running the POA. If you can't ping successfully, fix that problem before going further.

2.
Telnet to the POA. Run Windows Telnet by entering telnet from the Run prompt under the Start menu.

3.
When using Telnet, turn on Local Echo.

4.
Connect to the POA; the hostname should be the DNS name or IP address of the POA, and the port should be 1677, or whatever your client/server port is. Figure 23.4 shows a Telnet session.

Figure 23.4. A Telnet to the POA

[View full size image]

5.
Upon successfully connecting to the POA's client/server port, you should be allowed to type characters and press Enter several times. Also, after holding the Enter key for several seconds, you should be disconnected from the POA. If you can't get the connection to the POA at the client/server port, you've got some kind of a TCP/IP problem.

Tip

If you get a connection to the POA, hold down the Enter key, and then never get disconnected, that's actually an indication of a TCP/IP problem (for some reason, the POA cannot talk back to the client in order to close the connection).

If there are TCP/IP problems, it is appropriate to verify the TCP/IP settings or reinstall the TCP/IP services on the user's workstation. Itmight also be a good idea to break out the LAN sniffer and determine whether there is a network problem on this network segment.

Note

When using a LAN sniffer to help troubleshoot and diagnose problems between GroupWise components, you will not be doing any Application layer troubleshooting. This is because all data between GroupWise agents are encrypted. You will be looking for layer 24 problems on the TCP/IP stack when using a LAN sniffer to troubleshoot communication issues. An exception to this is SMTP traffic that is usually not encrypted.

Troubleshooting User-Specific Problems

If the problem can be reproduced on multiple machines, your problem is likely user-specific. Before you can classify a problem this way, however, you need to make sure that the problem isn't specific to the post office or network segment.

A good test is to go to a machine on the same network segment, or on the same network switch as the machine that seems to be giving the user problems. From that machine, log in as a different user than the problem user, but one who is on the same post office as the problem user. Does the problem persist? If so, the problem really isn't user-specific, and it's not machine-specific. The problem is either post officespecific or network-specific.

Components Specific to Users

Imagine that a problem looks as though it really is user-specific. It is still ideal to troubleshoot the problem away from the user's machine. There are just a few things that are truly specific to a user:

  • The user's object entry in the GroupWise directory: Only the user interfaces with his or her object entry in the WPHOST.DB file.

  • The user's master mailbox: This consists of the USER xxx.DB database file in the GroupWise information store at the post office, and any other store files it references for item content.

  • The user's caching mode or remote databases: If the user happens to use caching mode or remote mode, these files will be on the user's local drive. If you troubleshoot from a different workstation, GroupWise remote databases should not come into play.

  • The user's archive databases: If the user is archiving to a local drive, troubleshooting from a separate workstation should isolate the problem.

Isolating GroupWise Archive Problems

The GroupWise client interacts with the archive databases on three occasions:

  • When the GroupWise client first loads

  • When reading items from the Archive mailbox

  • When archiving a message item

The simplest way to determine whether a problem is an archive problem is to rename the user's Archive directory. To determine a user's Archive directory, do the following:

1.
In the GroupWise client, go to Tools, Options, Environment, File Location.

2.
Write down the Archive directory path.

3.
Determine the user's three-character FID.

In the GroupWise client, this information can be found under Help, About GroupWise. It's the three characters in the parentheses following the user's name, as shown in Figure 23.5.

Figure 23.5. The GroupWise FID as shown from the GroupWise client

The Archive directory is the file location of the archive plus OF xxx ARC (in which xxx is the user's FID). If the Archive directory is C:\ARCHIVE and the user's FID is 123, then the Archive directory therefore the user is C:\ARCHIVE\OF123ARC.

Tip

It is always a good idea to back up GroupWise archives before working with them. In fact, Novell recommends that GroupWise archives be placed on network drives so that they are backed up automatically. Do not use Novell's iFolder to manage GroupWise archive backups. Novell's iFolder can corrupt GroupWise archive databases.

4.
Rename this directory.

If this approach solves the problem, you know that the problem was with the user's GroupWise archive. You can now name it as before, and start taking steps to repair it using the standalone GWCheck for Windows (GWCHECK.EXE).

Tip

The GroupWise client has GWCheck within it. If you want to run a GWCheck on an archive database, hold down the Ctrl and the Shift keys simultaneously, and then choose File, Open Archive.

Isolating GroupWise Master Mailbox Problems

Generally, a problem is either in a user's database or in one of the message databases on the post office. The most likely culprit for problems is the user's USER xxx.DB file. Users can potentially destroy the contents of their USER xxx.DB files. For instance, a user can create a personal group with invalid addresses. If a user is complaining of a problem, and the problem is user-specific, begin by looking in the user's preferences and address book for clues about what is causing the problem.

If you already ran a structural rebuild on this user's database and you've reached this point, you might want some additional confirmation that you are looking in the right place. One way to do this is by renaming the user's user database. This is a common troubleshooting step:

1.
Make sure that the user is out of GroupWise.

2.
Rename the user's USER xxx.DB file to USER xxx.OLD.

Note

You might have to bring the POA down to release this file. Just unload the POA, and then while the POA is unloading, go to the NetWare Console prompt and immediately reload the POA. Users who are in GroupWise will automatically reconnect to the POA, and there is generally a negligible interruption of service.

3.
Using the standalone GWCheck utility, specify the following, as shown in Figure 23.6:

  • Database Type: Post Office.

  • Database Path: Specify the path to the post office that the user is on.

  • Post Office Name: Specify the name of the post office that the user is on.

  • Object Type: User/Resource.

  • User/Resource: The problem user's USER xxx.DB file.

  • Action: Structural Rebuild (not Structure Analyze/Fix Databases).

  • Databases: User.

Figure 23.6. Using GWCheck to drop a USER xxx.DB file from the guardian database

[View full size image]

4.
Click Run.

When GWCheck runs, it will report, among other things, an error 26. This error is good. It means that GWCheck will remove the registration of problem user's USER xxx.DB from the NGWGUARD.DB file. The system will now allow you to create a new USER xxx.DB file for this user.

Tip

You might have to bring the POA down again. When you go to load the GroupWise client, you could get a C05D error. A C05D error indicates that the USER xxx.DB file is registered in the NGWGUARD.DB file but is not on the disk. You just unregistered the USER xxx.DB file from the NGWGUARD.DB file, but the POA has it cached in memory. Bringing down the POA and bringing it back up fixes this issue.

5.
Run GroupWise as the problem user.

The email box will be empty. Do the same action that caused a problem before. Does the problem still exist? If not, you know that the problem was wholly contained in the USER xxx.DB file that was renamed to USER xxx.OLD. If the problem does still exist, you are looking at a problem with the post office database, or perhaps you have not correctly ruled out machine- or network-specific problems.

6.
Whether or not the problem was isolated to the user database you renamed, you should now rename the new USER xxx.DB file something else, and rename the USER xxx.OLD file back to USER xxx.DB.

Again, you might need to unload and reload the POA to force the release of the file.

The next section gives more ideas on how to proceed, now that you know that the problem is in the USER xxx.DB file.

Fixing Master Mailbox Problems

Suppose that in step 5 in the preceding section you isolated the problem to this user's database. Now what should you do? The following are some actions you can try:

  • If you didn't synchronize the user object, do so now.

  • If you didn't run a structural rebuild on the user's database, do so now.

  • If you didn't run a contents check on the user's database, do so now.

  • Run a Reset Client Options operation on this user from Tools, GroupWise Utilities, Mailbox/Library Maintenance.

  • Run an index check on the user's database.

  • Rid the user of the personal address book(s) and the entries in the frequent contacts address book list.

    You can export each of these books from the client, and then delete all the entries in each of these address books. When you have finished your testing and troubleshooting, you can reimport these entries.

    To export an address book, go into the GroupWise address book and choose File, Export. Make sure that you are not exporting the GroupWise system address book. Just export the frequent contacts and the user's personal address books.

If none of these steps resolves the problem, and the problem is really causing the user some headaches (which is to say, you cannot tell the user just to ignore the problem), you have two options:

  • Use the Re-create User Database option. This routine could possibly fix the problem, but things will be pretty disorganized when the user goes back into his or her mailbox. All personal items will be thrown into the root of the mailbox Cabinet folder. The user's personal calendar items will also be lost.

  • Archive everything. You can archive everything that the user has, and then give the user a new, empty user database. Then you need to unarchive the items into the new database.


Generating a Fresh User Database Without Losing Items

This walkthrough helps you create a new USER xxx.DB file for the user without losing any GroupWise messages and calendar items.

Exporting a User's Mailbox

Those of you familiar with the Archive feature might wonder why this section is called an exporting process. Users' mailboxes aren't just composed of messages; they're also the folder structure the users have created, their address books, their calendar items, even their trash items. People are rather sensitive about their mailboxit can be an office of sorts. You won't be able to restore shared address books, shared folders, rules, and personal preferences, but you should take care to restore everything you possibly can.

Configuring the Archive Directory

You first need to specify an archive location in order to create an Archive mailbox. Before we get into how to do this, take some precautions. We have had experience in the past with Windows caching data rather than writing it to the hard drive. When you are archiving so much data, it is often better to specify the archive path to a NetWare server. The NetWare client does a much better job than Windows does of handling data, which decreases the likelihood of corrupting the Archive mailbox when you're archiving a lot of data at one time.

Here are the steps for specifying the Archive directory:

1. | From inside the user's mailbox, select Tools, Options, Environment, File Location, Archive directory.
2. | Specify an Archive directory. Be sure to specify a new archive path; do not archive to an existing Archive mailbox. Using an existing mailbox would mix messages that the user intends for the Archive mailbox with messages intended for the master mailbox.
Configuring the Mailbox Folder Structure for Export

Many users have created an elaborate folder structure under their mailboxes and cabinets. When you archive messages, the folders containing messages are automatically created in the Archive mailbox. When you eventually unarchive the items, those folder names are re-created in the live mailbox. Folders containing no messages, however, will be lost. Again, the idea is to try to make the mailbox look as it did before it was deleted.

Following are the steps for preserving a mailbox folder structure:

1.
Find one small message item in the user's mailbox that you will use for helping you to easily export the folders in this mailbox.

2.
Highlight the item and select Edit, Move/Link to Folders.

3.
In the resulting Move/Link Selections to Folder dialog box, place a check next to each folder within the Cabinet object. If the user has other folders under the mailbox that are not in the Cabinet, you can place check marks next to those. Figure 23.7 shows an example of this step.

Figure 23.7. Linking a message item to all folders

4.
With the check marks in place, click the Move button. This makes a virtual copy of this message in every folder in the mailbox. Get out of the Move/Link option. When you archive the folders, every folder will be created because there is an item in each of the folders.

Exporting All Messages Items

Now you are going to export the real meat of the mailbox. The easiest way to see that you get everything in the mailbox is to use the Find feature in the GroupWise mailbox.

When you choose Tools, Find, make no additional selections from the Find dialog box, and click the OK button, you are actually telling GroupWise to find everything. And you'll see, everything will come up in the Find window. If this user is tidy, or if you have an aggressive email retention policy, perhaps you'll see just a few hundred items. However, you are more likely to see thousands and thousands of items. The problem with this is that the Find window will not display that many items. You might therefore need to alter your Find query to find only items from a certain time period or of a certain type.

You can, for example, alter the scope of the query by using the Date range section. You can specify a three-month range, and issue the Find, archive the items, and then modify the find from the Find window by selecting Tools, Modify Find. The idea is to get a maximum of about 4,500 items in the Find window, and then modify the Find window to get the next batch of items. Your goal is to eventually find, and then archive, all the message items in the user's mailbox.

Here are the basic steps for doing this; you might need to deviate from them to narrow the query a bit:

1. | Inside the user's mailbox, select Tools, Find. Make sure that the Find tab is active, not the Find by Example tab.
2. | Accept the defaults and click the OK button. If you suspect that this user has more than 4,500 items in the mailbox, modify the find by using the Date Range feature.
3. | Select the first 500 or so items with a Shift-click of the mouse. Select Actions, Move to Archive.
4. | Repeat step 3 (and possibly step 2) until all items are moved to the Archive mailbox.

This process of archiving the items from the Find query should find calendar items, be they group or personal calendar items, and all message items, whether sent or received. Ideally, this process will move all message items from the master mailbox to the Archive mailbox. When you get finished, the mailbox should look like a ghost town, perhaps containing a bunch of empty folders.

Tip

Although this manual method works very well, it can be time-consuming. In the past we've been using tools created with the Advansys Formativ development framework which completely automates the archiving and unarchiving of a mailbox, including the users' address books. You can find more info about Formativ at www.advansyscorp.com.

Exporting the TrashIt's Quick!

You might think this is crazy, but exporting the trash adds to the psychological effect of what you are doing. If you bring back the user's trash, that person will think you performed wonders, yet it takes just a minute:

1. | Create a new folder in the cabinet of the user's mailbox (not the Archive mailbox), called trash2.
2. | Go to the trash and Shift-click to select all items. Drag them to the new trash2 folder you created.
3. | Go to the trash2 folder you created under the cabinet, Shift-click to select all items, and select Actions, Archive.

Note

Later, you will move these trash items in the trash2 folder back to the trash bucket in the user's live mailbox.

Exporting the Address Book

Every user has at least two address books and quite often more than that. These two address books are the Frequent Contacts address book and the address book named as the user's full name. The user you are working with might even have more. You can export the user's address books, and then later you will import them into the new mailbox.

Following are the steps for exporting personal address books:

1.
Go to the GroupWise Address book by selecting Tools, Address Book.

2.
Choose a personal address book to export by clicking the tab of the address book (not the Novell GroupWise address book; that's your system address book, not a personal address book).

3.
Inside the address book, choose File, Export, Entire Address Book. Figure 23.8 shows this dialog box.

Figure 23.8. Exporting the GroupWise personal address books

4.
Save the file as a *.NAB file. You might want to name the *.NAB files according to the name of the address bookfor example, TKRATZER-Frequent Contacts.NAB.

You've exported everything you possibly can. Now you need to rename the user's database and drop it from the guardian database (NGWGUARD.DB).

Following are the steps for removing a user's database and dropping the user's registration from the NGWGUARD.DB file:

  1. Note TKRATZER's FID: Determine what TKRATZER's FID is. If GroupWise is loaded, and you're logged in as TKRATZER, choose Help, About GroupWise. The FID is in parentheses next to the user's name.

  2. Rename TKRATZER's user database: Now you need to rename TKRATZER's user database file. You know that TKRATZER's FID is 5NW. The file you are looking for, USER5NW.DB, is in the OFUSER subdirectory of the user's post office directory. Rename the file to USER5NW.OLD.

Note

As discussed earlier in the chapter, the POA might need to be unloaded before this database can be renamed.

Renaming TKRATZER's USER xxx.DB file is not enough. The USER5NW.DB file is registered in the NGWGUARD.DB. Now you must "drop" the USER5NW.DB file (that you renamed to USER5NW.OLD) from the NGWGUARD.DB. Following are the steps for doing this:

1.
Run the standalone GWCheck utility, as shown in Figure 23.9.

Figure 23.9. Using GWCheck to drop a USER xxx.DB file from the guardian database

[View full size image]

2.
Specify the following:

  • Database Type: Post Office.

  • Database Path: Specify the path to the post office that TKRATZER is on.

  • Post Office Name: Specify the name of the post office that TKRATZER is on.

  • Object Type: User/Resource.

  • User/Resource: USER5NW.DB.

  • Action: Structural Rebuild (not a structure Analyze/Fix Databases).

  • Databases: User.

3.
Click Run.

The GWCheck log will indicate an error 26; you should expect and want this error. See Figure 23.10 for an example of this. These are the items to pay attention to:

  • Access and test the clean mailbox: It's time for a sanity check. Launch GroupWise as the user (using the /@u-? switch). The mailbox should be empty. Make sure that you can no longer duplicate the problem the user was having. If you can still duplicate the problem, this whole exercise is pointless. You probably did not correctly determine the specificity of the problem.

    Tip

    Remember, if you get a C05D error when loading the GroupWise client, you need to bring the post office's POA down and back up again.

  • Restore items from the archive: Assuming that the problem can no longer be duplicated, it is time to begin the process of moving items from the Archive mailbox back into the master mailbox. See the next section for how to do this.

Figure 23.10. GWCheck should give an error 26

[View full size image]

Importing a User's Mailbox

When you get into TKRATZER's live master mailbox, the steps are nearly the reverse of the export process steps, of course. First, though, in order for the Find feature to work on the Archive mailbox, you must access the Archive mailbox, and then exit GroupWise. GroupWise needs to rebuild the QuickFinder index on the Archive mailbox. Exiting GroupWise after GroupWise has discovered that it has new indexing to do causes the QuickFinder index for the Archive mailbox to be rebuilt, which helps the Find feature work properly.

Importing Mail/Folders and Trash Items

Following are the steps for importing folders and trash items from an Archive mailbox to a master mailbox:

1. | Get into the user's live GroupWise mailbox.
2. | Go into Tools, Options, Environment, File Location, Archive directory. Specify the Archive directory that you specified earlier in this chapter.
3. | Go into the Archive mailbox by selecting File, Open Archive. Then exit GroupWise. (On older GroupWise clients, this allows GroupWise to reindex the Archive mailbox.) The index is essential when using the Find feature in step 4.
4. | Get back into GroupWise and select File, Open Archive. From within the Archive mailbox, select Tools, Find. Find items in the same manner in which you did when you archived messages into the Archive mailbox. Be sure to select the Find tab, not the Find by Example tab. (If the Find feature does not find any items, try exiting GroupWise again.)
5. | Select the items in the Find Results view and choose Actions, Move to Archive (this actually unarchives the items and moves them back to the master mailbox).
6. | Repeat step 5 until all items are unarchived. Get into the master mailbox (rather than the Archive mailbox). You should see your message items, and all the folders that were created. You still need to deal with the trash.
7. | Make sure you're in the master mailbox, not the Archive mailbox. Go to the trash folder under the cabinet. Delete this trash2 folder under the cabinet, as well as all the messages in the TRash2 folder. This will move the messages to the trash bucket on the master mailbox.

You restored/imported all the message data, and it should show up in the master mailbox. There is more data that needs to be imported, as explained in the next section.

Importing the Address Books

The import process is, of course, the opposite of the export process you performed earlier.

Inside the GroupWise address book, you should see at least two personal address books. They are the Frequent Contacts address book, and the address book with the same name as the user's full name. Follow these steps to import them both:

1. | Highlight one of the address book tabs for an address book you will import, and select File, Import.
2. | Specify the correct *.NAB file for this address book. This is going to be the *.NAB file that you exported earlier.
3. | If the user has more than the two default address books, you have to create the address book tabs for these address books before attempting to import the *.NAB file. To do this, select File, New Book, and create the address book with the same name it had before.

Now the user's personal address books are imported.

Final Notes on the Import Process

The import process did not import the following less common attributes about a mailbox:

  • Rules

  • User preferences

  • Saved Find folders

  • Button bar settings

Earlier in the solution, you might have linked a message item to several folders, in order to re-create the folder structure. You don't want that item linked to all the folders. Do the following:

1. | Find one instance of that message item that is linked to all the folders.
2. | Forward the message as an attachment from Tay Kratzer to Tay Kratzer. This way, the message isn't lost.
3. | Archive the one item, and it will no longer be in all the folders. Then you can delete the archive; it's no longer needed at this time.

Here are the final things to pay attention to in order to set the mailbox as close to how it was before it was re-created:

  • Set the archive path back to the original archive path that TKRATZER had, if they had an archive path. Do not select the option to move items.

  • Set up proxy access.

  • Set up shared folders.

  • Request shared folders from others who have shared folders with TKRATZER.

  • Set up shared address books.

  • Request shared address books from others who have shared address books with TKRATZER.

Now you've completely re-created a mailbox database.


Summary

This chapter explained using the scientific method as a means of troubleshooting. The scientific method is a four-step process:

1. | Observe.
2. | Hypothesize.
3. | Predict based on the hypothesis.
4. | Test the hypothesis.

This chapter discussed that problems are generally either one or the other of the following:

  • User-specific

  • Machine-specific


Chapter 24. Using Wireless and Handheld Devices with GroupWise 7 WebAccess

This chapter discusses using handheld devices and wireless access to the GroupWise mailbox. WebAccess was covered in Chapter 11, "Installing and Configuring GroupWise WebAccess," so you should be familiar with it and with its different components. If you have not already read Chapter 11, go back and do so before starting this chapter.

This chapter will help you better understand how access from wireless and handheld devices works through WebAccess. It will also give you an understanding of how modular and flexible GroupWise WebAccess is in regard to providing future support for all sorts of devices and protocols, one of the major advantages of the GroupWise WebAccess architecture.


Understanding Templates

GroupWise WebAccess uses templates that facilitate access to the GroupWise mailbox from many different devices. Think of templates as a skeleton document that the WebAccess application stuffs the data into before displaying it to the connected client's device. This data is from the user's mailbox and is delivered to the WebAccess application from the WebAccess agent. If you are using a wireless phone to access your GroupWise mailbox through WebAccess, the application recognizes the type of device it is communicating with. As a result, when the data is received from the user's mailbox, the application will place this data (the mail items, for example) into a template that has been designed to work with wireless phones using the wireless access protocol (WAP).

The use of templates at the application level allows Novell development engineers to easily add support for additional devices. No coding changes need to occur at the agent level.

The WebAccess templates are stored on the web server. On a typical NetWare 6.5 server running an Apache Web server and the Tomcat servlet gateway, the templates are found in the following location:

SYS:tomcat\4\webapps\ROOT\WEB-INF\classes
\com\novell\webaccess\templates

On a typical installation on a SUSE Linux/NetWare OES Linux Kernel server running an Apache Web server and the Tomcat servlet gateway, the templates are found in the following location:

/var/opt/novell/tomcat4/webapps/gw/WEB-INF/classes
/com/novell/webaccess/templates

Out-of-the-Box Templates Included in GroupWise 7

The templates that ship with GroupWise 7 support the following devices or browsers:

  • Web browsers that support CSS (an enhanced form of HTML).

  • Web browsers that use simple HTML. This is usually what a Pocket PC is equipped with. The web browser that comes in a Tungsten T, which is made by Novarra.com, also works nicely as a simple HTML browser.

  • Wireless phones that support WML (wireless markup language) through the WAP protocol (wireless access protocol).

  • Palm OS devices, as well as other devices that support the web clipping technology developed by Palm.

If you were to look at the template directories, you would note the following directories:

  • CSS: The CSS directory contains the templates that most of the standard PC-based web browsers will use (Netscape and Internet Explorer, for example).

  • FRAMES: The FRAMES directory contains the templates that can be used by PC-based web browsers that cannot use CSS.

  • HDML: The HDML directory contains the templates that handheld devices use. HDML stands for the handheld device markup language. It is similar to HTML, but scaled down for handheld-device use. Many cell-phone devices support HDML.

  • SIMPLE: The SIMPLE directory contains the templates for devices that use the simple HTML interface. A growing number of devices and browsers use simple HTML, including Pocket PC devices running the Microsoft Pocket PC/Windows CE OS. Another example of a simple HTML device is a web TV appliance.

  • WEBCLIP: Web clipping technology is used with the Palm OS products. The Palm OS version 3.5.1 through all Palm OS 4.x devices support the proprietary web clipping technology created by Palm Inc. Devices from Palm OS 5 on have dropped support for web clipping.

  • WML: The WML directory includes the wireless markup language templates that are used primarily by wireless phones. Another name for WML is WAP. WAP browsers exist for various platforms.

These are all the templates that currently ship with GroupWise 7, but as WebAccess supports more client types, there will be more templates.

Managing Templates Through the GroupWise WebAccess Object

There are a few things that you as an administrator can configure regarding templates. You administer the GroupWise templates by accessing the properties of the GroupWise WebAccess object in ConsoleOne. From the Application property page, shown in Figure 24.1, select Templates from the drop-down list. From here, you can determine how the templates are configured.

Figure 24.1. The WebAccess Application Templates property page allows you to define general information for the WebAccess Templates

[View full size image]

Following is an explanation of the Templates property page settings:

  • Template Path: This is the path to the template directories. Under this path, you will see a directory representing each of the installed templates.

  • Java Package: A Java package name is a directory path that uses the period (.) instead of a slash (\) to separate components of the path. Hence, this is really just a path that you are looking at here. Basically, this points to the same directory as the Template Path field, identifying the location of the template string tables. Unless you are a developer and creating your own custom templates, you will never need to modify this path.

  • Images URL: This is the path to the image files. This path, under the web server, contains the image files (*.GIF) that the different templates will display.

  • Applets URL: This field allows you to define the path to any custom applets you are using. It is possible to use Java applets for some of the WebAccess components. This is most commonly seen if you want to develop custom address-book or calendar views.

  • Help URL: This is the path under the root of the web server to the location of the help files. You can move the help files to a different location, if desired.

  • Enable Template Caching: This option allows the WebAccess application to cache the templates in RAM the first time they are used, which increases performance.

  • Cache Size: This value determines how much RAM the server will use to cache the templates.

  • Default Language: This option determines the default language presented to users when they visit your web server's home page.

There are even more settings related to templates; the next section discusses these.

Defining User Interface and Browser Integration

This section explains what the Define User Interfaces window, shown in Figure 24.2, allows you to do. It describes each of the three property pages and what they mean in relation to the templates.

Figure 24.2. User interfaces are used to define the different templates available to the WebAccess Application

[View full size image]

User Interfaces

The User Interfaces tab shown in Figure 24.2 allows you to define the available templates. You can add references to templates, if needed. However, the templates have to be ones that you created; the six listed in Figure 24.2 ship with GroupWise WebAccess.

Following is an explanation of the User Interfaces property page:

  • User Interface: This defines the name of the template.

  • Template: This is the actual name of the directory under the template directory, as defined earlier.

  • Content Type: This option defines the type of content this template can serve. In other words, it defines what type of content the receiving device can handle.

Generally, you do not modify the information on this page. You will do so only if you introduce new templates to WebAccess.

Browser User Agents

The Browser User Agents tab shown in Figure 24.3 enables you to associate a user interface or template with a particular type of web browser. The WebAccess application makes this association based on the browser identifying itself to the WebAccess application.

Figure 24.3. Browser User Agents defines popular browsers that are used on non-PC-based devices

[View full size image]

Just about every browser identifies itself with a Browser User Agent value. This can include the platform, version of browser, and so on. In other words, if a browser's user agent information includes Windows CE (this would be in the header of the data sent to the WebAccess Application from the user's browser), the application will use the basic HTML interface (or the simple templates) and not the default frames, which are defined under the User Interfaces tab.

The nice thing about this design is that you can easily add new browsers here.

Following is an explanation of the information on the Browser User Agents property page:

  • Browser User Agent: Here, you identify what a browser can use to identify itself to the WebAccess application.

  • User Interface: This column defines the template or user interface that will be delivered to the device when a match is made from the Browser User Agent list.

It is quite feasible that you might define additional browser user agents. The idea for doing this is explained later in this chapter.

Browser Accept Types

The Browser Accept Types tab also lets you associate a user interface or template with a particular type of web browser. However, this association is based on the content type the browser will accept, not the browser identifying itself. For example, if a browser accepts text/html (one of the predefined entries), the WebAccess application will use the standard HTML interface (or the Frames templates). Most browsers will accept multiple content types, including text/html or text/plain. The content type identifies what type of information the browser can understand.

Many browsers accept more than one content type, such as both text/html and text/plain.

Following is an explanation of the information on the Browser Accept Types property page:

  • Browser Accept Type: This option identifies what format the data can be in when the browser receives it.

  • User Interface: This option defines the templates that deliver this type of content to the browser.

So, in a nutshell, the Define User Interfaces window allows you to identify and configure which sets of templates are associated with different types of browserseverything from standard browsers to wireless phones.

Note

If you edit and make changes in the Define User Interfaces window, this information is written to the WEBACC.CFG file. The WebAccess application does not dynamically read this file. To get these changes to take effect, you must shut down and restart the WebAccess application.

How the WebAccess Application Detects Which Templates to Use

Given the numerous templates available, the WebAccess application needs to somehow know what templates to use. It must use the correct templates for the different types of browsers and devices it supports.

When a device is directed to the URL that points to the GW\WEBACC location on the web server, it sends a small packet that contains header information about the browser being used. This header information contains information that helps to identify the Browser User Agent. An example of what a Pocket PC 2000 device might send is the following:

Mozilla/4.0 (compatible; MSIE 4.01; Windows NT Windows CE)

The WebAccess application then reads the cached information from the WEBACC.CFG file. This is how it determines what type of browsers it can support.

If the information from the browser contains the Browser User Agent name (Windows CE in this example), the application knows to use the associated template listed in the User Interface column.

If the browser has not provided the Browser User Agent name, the WebAccess application will try to determine what type of data the browser can understand. This information is configured in the Browser Accept Types options. If the browser identifies that it can understand text/x-hdml, the WebAccess application knows that it is probably talking to a wireless phone that is expecting data in the x-hdml format. The WebAccess application then checks the User Interface value to determine which templates to use when corresponding with the device.

If the WebAccess application still is not sure what type of device it is communicating with, it will go to the User Interface value and use the default template there.

This background should help you understand how the WebAccess application works. The application understands what device or browser it is communicating with, as well as what set of templates to use when communicating to a device.


Accessing Your GroupWise Mailbox from a Pocket PC Device

GroupWise wireless requires a Windows CE or Pocket PC device that supports IE version 4.0 or better. To determine the version of IE that comes with a Windows CE device, go to the Control Panel and the System icons.

To access the GroupWise WebAccess system from a handheld device running the Pocket PC or Windows CE OS, you must first have some way to get online with the device. You have a couple of options for getting online with your Pocket PC device. You can use a modem with the Pocket PC device and dial a traditional ISP to get Internet access. You can also use a wireless LAN card with the Pocket PC device, which places you on a corporate network, if this service is available to you. Many wireless phone providers also offer a card that allows you to access the Internet through their network. Check with your wireless phone provider to determine which solutions they offer in this arena.

After you are online and have access to the web server where the GroupWise WebAccess application is running, you can enter the URL of your WebAccess server, for example, http://groupwise.wwwidgets.com/gw/webacc.

The Pocket PC device should tell the web server that it is a Windows CE user agent, and the WebAccess application will use the simple templates to display the mail. Figure 24.4 shows an example of what the simple interface looks like on a Pocket PC/Windows CE device.

Figure 24.4. WebAccess simple HTML interface

Notice from Figure 24.4 that you do not get all the graphics that the traditional GroupWise WebAccess view gives you. You will also notice that the simple templates are designed to fit on a much smaller screen. This is very helpful when you're using a Pocket PC device because it eliminates much of the scrolling across the screen to view the entire contents of the mailbox.

If you need to test whether the simple templates are working, but you do not have a simple HTML device, you can tell the WebAccess application which templates you want to use via the URL line. Here is an example of how to specifically tell the WebAccess application that you want to use the simple templates:

http://yourwebserverver DNS name/gw/webacc?User.interface=simple

Note

The "User.interface=simple" code is case sensitive.

When you press Enter, the WebAccess application displays the login page using the simple templates. When you log in, the screen looks as shown in Figure 24.5.

Figure 24.5. WebAccess simple HTML interface on a PC browser

[View full size image]


Defining a New Browser User Agent Type

Consider the following scenario, which illustrates the value of this information. A user has a Tungsten T, which is a Palm OS 5 device. This device comes with a browser called Web Pro, made by Novarra. The Web Pro browser uses a proxy server, and the proxy server helps make HTML pages digestible to the Web Pro browser. Either the Web Pro can use normal HTML, with frames and the like, or it can use simple HTML. When the user uses the Web Pro browser to visit WebAccess using the simple HTML templates, the performance is much better than when using the regular HTML/Frames templates.

When the user first used GroupWise WebAccess with the Web Pro browser, the performance was very slow. You then instructed the user to change the URL on the Web Pro browser to indicate to WebAccess that the device was using a simple HTML browser. The WebAccess session's performance becomes much better. Following is the syntax the user used to force the WebAccess Application to serve up simple HTML:

http://groupwise.wwwidgets.com/gw/webacc?User.interface=simple

Typing this long URL once and then bookmarking it is not too difficult, particularly for a technical person. But imagine you have a bunch of users who want to access GroupWise WebAccess from their Tungsten T. Wouldn't it just be better to have GroupWise WebAccess detect the Web Pro browser type, and then give the users the simple HTML templates automatically? Of course. So here's how you can do this:

1. | In ConsoleOne, edit the GroupWiseWebAccess Object from the eDirectory browser view. This is the WebAccess application's GroupWise WebAccess object.
2. | From the Application tab, select the Templates property page.
3. | Click the Define User Interfaces button.
4. | Go to the Browser User Agents tab and click the Add button.
5. | Enter *WebPro* in the Browser User Agent field. This means that if the browser identifies itself to the web server with a string that contains WebPro, the WebAccess Application correlates it with the Browser User Agent defined in step 5.
6. | Change the User Interface drop-down list box to read Basic HTML.

If a web browser identifies its Browser User Agent information with a string that contains WebPro, the WebAccess application uses simple HTML templates.

You must stop and restart the web server and the Java servlet gateway that are hosting the WebAccess application for these changes to take place.


Accessing Your GroupWise Mailbox from a Wireless Phone

To access the GroupWise mailbox from a wireless phone, there are a few prerequisites that must be met. First, the phone must support the wireless application protocol (WAP). WAP was designed to allow wireless applications to work across different wireless network technology types. It was developed by the WAP Forum, which consisted of various wireless venders. Think of WAP as the vehicle that carries the data to your cell phone.

To clarify why GroupWise WebAccess uses WML and HDML templates instead of a WAP template, you can think of WAP as the vehicle that brings WML or HDML content to a wireless device. WML (wireless markup language) and HDML (handheld device markup language) are the actual text documents that display content, and they sit on top of the WAP protocol. Hence, GroupWise uses the WML and HDML templates to create the content, which is delivered over the WAP protocol to the wireless device.

If you have a WAP-enabled phone, the next step is to make sure that the phone service provider provides WAP service to the phone. Otherwise, you have this nice gadget that is acting like a traditional cell phone. You will not be able to access the GroupWise mailbox from it because you have not subscribed to this service.

With a WAP phone and a subscription from the cellular phone service provider, you should be able to access the web server where your GroupWise WebAccess application is running. On the phone's browser, you enter the URL of the web server that is running the WebAccess application.

Note

If the web server does not have any WML or HDML pages to display, you will not be able to see the HTML web page that is the default from a WML/HDML device. You need to enter the /GW/WEBACC portion of the URL to direct the phone browser directly to the WebAccess application; for example, yourwebserverver DNS name/gw/webacc.

When your phone accesses the GW/WEBACC page, you will be presented with a prompt to enter the GroupWise user ID. After entering the user ID and clicking OK, you will be prompted for the GroupWise password. You will then be given a simple menu option consisting of Mail, Appointments, Tasks, Address Book, Compose, Documents, Options, and Logout. You can scroll through them to perform different tasks. Figure 24.6 shows GroupWise wireless on a cell phone.

Figure 24.6. WebAccess simple WML interface

As an administrator, you can test WebAccess to verify that you can access your mailbox from a WAP-enabled cell phone. Instead of just telling the web browser to use the WML or HDML templates, you must use a WAP phone emulator. The reason for this is that the standard browsers out there do not support the WML or HDML protocols. WML was specifically designed for small handheld or wireless devices, and is not supported by the traditional web browsers.

To test with a WAP emulator running on any Windows OS platform, go to www.openwave.com and download the OpenWave Phone Simulator. The Phone Simulator has a very simple install process for installing the WAP phone emulator. After it's installed, you can enter the URL in the GO field and press Enter. It should connect you to the URL that you specified and allow you to log into the WebAccess mailbox.


Information Regarding SSL-ized Connections from Handheld Devices

Many installations of GroupWise WebAccess are using SSL to encrypt the data between the browser and the WebAccess application. This is advisable for security reasons. There are a few issues regarding this and using handheld or wireless devices to access WebAccess.

For the web server to communicate with a web browser, they must exchange certificates. As a result, the device that is accessing the WebAccess system must be able to support certificates. Most of the handheld and wireless devices come preconfigured with a set list of trusted root certificate authorities. What this means is that if you have used Novell's certificate server to generate a certificate for the web server, you will not be able to use the handheld devices to access WebAccess. You must request and install a certificate from one of the certificate vendors that the device has in its trusted root list.

If you're using a cellular phone to access WebAccess that has SSL enabled on the web server, you must check with the cellular phone service provider to ensure that its gateway has your web server's certificate issuer on its trusted root list. Otherwise, the data will not pass through the cellular phone's network and down to your cell phone.

The safest thing is to have the web server use a certificate that was obtained from a vendor contained in the trusted root list of the devices that will be used to access the WebAccess system. Chapter 27, "Securing Your GroupWise System via SSL," includes some pointers about how to enable a certificate on a NetWare platform web server.


Summary

This chapter has described how WebAccess works with some of the more popular handheld and wireless devices on the market. There are many other devices that also work with WebAccess. If they support HTML, simple HTML, WML, or HDML, they should be able to access the GroupWise mailbox through WebAccess.

The wireless and handheld device support in GroupWise 7 WebAccess components is very impressive, and adds a lot of value for your users.


Chapter 25. Configuring a Spam/Junk Mail Control Solution

First let's define spam. The Coalition Against Unsolicited Commercial Email (CAUCE) defines spam as unsolicited commercial email. In the CAUCE definition, spam includes commercial proposals for products or services, or as part of a money scam, and is overtly intended to trick recipients by making the email seem relevant to them.

This chapter introduces the elements of GroupWise that can assist in handling spam. There are also some recommendations about solutions for managing spam that do not come with GroupWise.


Is Spam Really a Problem?

Some folks don't think spam really is a problem, and that's because they haven't given out their email address, and a spammer hasn't harvested it. Spam is currently the biggest scourge of the Internet. The estimates are that more than 55% of all emails can be marked as spam, and this is of course eating up an enormous amount of valuable resources. Here are some of the hidden costs of spam:

  • False-positives (pertinent messages are blocked)

  • Identity theft

  • Loss of productivity

  • Security breaches (open relay attacks)

  • Increased operation costs

  • Downtime (denial-of-service attacks)

  • Loss of reputation (placed on a realtime blacklist [RBL])

  • Legal liabilities

  • Lost employee confidence

This chapter introduces you to the features in GroupWise that can act as a piece of your spam solution. However, it is important to note that you should not rely wholly on the spam-control features in GroupWise; they are not sufficient to block the wide variety of spam messages out there.

We highly recommend that you look into a spam solution such as those from Novell's GroupWise partners. We will not make a recommendation as to which product you should buy; we simply recommend that any one of these solutions is better than nothing.


GroupWise Spam/Junk Mail Solutions

The following are actions you can take in GroupWise in an effort to control spam and junk mail. Let's cover the GWIA-based solutions first:

  • Reject the mail if the sender's identity cannot be verified

  • Protect against mail bombs

  • Implement access control

  • Utilize blacklists

In terms of client-based solutions, you can also implement a junk-mail handling procedure within GroupWise.

Implementing GWIA-Based Spam Solutions

The following sections cover features of the GWIA that can be used to combat spam.

Reject Mail If Sender's Identity Cannot Be Verified

In the SMTP protocol, an SMTP host that is trying to transmit to another SMTP host identifies itself with a DNS name. Spammers' SMTP hosts often identify themselves incorrectly or do not identify themselves at all.

The GWIA can be configured to test the identity of an SMTP host. This configuration setting is called Reject Mail If Sender's Identity Cannot Be Verified. This configuration feature is available on the Security Settings property page under the SMTP/MIME tab on the GWIA gateway.

What actually happens is that whenever your GWIA is prompted for a connection with another SMTP server, it reads the IP number of this other server. The GWIA then accesses the DNS to do a reverse address lookup, using the IP address to find the hostname for this other server. The GWIA then compares this information with the hostname as presented in the session and rejects the connection if these names don't match.

There is a downside to this setting, however. Many legitimate SMTP hosts on the Internet will not identify themselves or at least will not identify themselves correctly. This is a common issue with many SMTP hosts on the Internet. So if you enable this feature, be prepared for the fact that you might reject legitimate mail.

Mailbomb Protection

Mailbomb Protection is another setting on the GWIA's Security Settings property page. This setting is generally a safe setting to implement. Mailbombs are generally different from spam. The nature of a mailbomb is that SMTP HostA contacts SMTP HostB and sends messages to HostB in rapid succession. Generally, the goal of a mailbomb is for HostA (the mailbomber) to overpower HostB, causing the SMTP HostB to be overwhelmed by the volume of mail, and perhaps crash because of the volume. Most spammers are not trying to make SMTP hosts crash, so they do not use mailbomb techniques.

Access Control

The features available under the Access Control tab are the most effective tools you have in GroupWise to curtail spammers. The most important feature is called Prevent Message Relaying, as shown in Figure 25.1.

Figure 25.1. The Prevent Message Relaying feature on the GWIA

[View full size image]

Spammers are constantly searching the Internet for SMTP hosts that will allow the spammer to relay its messages. Relaying is a part of the SMTP protocol that allows HostA to relay a message it wants to get to HostC through HostB. HostB then sends the message to HostC. If you were to allow message relaying, your GWIA could be used like HostB in this example. The impact to you might be that other SMTP hosts on the Internet might identify your host as a spamming host. Because of this, your SMTP host might become blacklisted. (Blacklists are discussed later in this chapter, but in short, being on a blacklist means that many other SMTP hosts on the Internet will not receive messages from your site.)

The GWIA will allow POP3 or IMAP4 users to relay through the GWIA, if they have already authenticated to the GWIA for a POP/IMAP session, prior to trying to relay off of the GWIA. If you have POP3/IMAP4 users, this kind of relaying is fine. It requires that a client that wants to relay through your GWIA have a mailbox within your system, and be authenticated to that mailbox, in order for the GWIA to allow the client to relay. It's important that your users configure their POP3/IMAP4 clients to authenticate before trying to relay. For example, in a popular POP3 client such as Microsoft Outlook Express, this is what you must do to enable authentication before relaying messages:

  1. Select Tools, Accounts.

  2. Highlight the Server definition/connection that represents the GWIA.

  3. Click the Properties button.

  4. From the Properties page, click the Servers tab.

  5. Select the option My Server Requires Authentication.

These steps force Outlook Express to authenticate via the POP3 or IMAP4 credentials that the user has provided, each time the users tell their Outlook client to relay off of the GWIA.

You might have other devices in your organization that need to relay off of your GWIA but are not sophisticated enough to authenticate. For these scenarios, it is often best to set up a special-purpose GWIA within your firewall. This GWIA can send messages out on the Internet, but no hosts on the Internet can contact this GWIA. This GWIA would be configured to Allow Message Relaying. With this type of a configuration, only hosts on your intranet would be able to relay off of the special-purpose GWIA.

Creating Blacklists

TheGroupWise GWIA supports the use of blacklists or RBLs (realtime blacklists). There are a couple of kinds of blacklists. Those relevant to the subject of spam are spam blacklists and open relay blacklists (relaying was covered earlier in this chapter). Blacklists are lists compiled by hosts on the Internet that indicate which DNS addresses and IP addresses have SMTP hosts that are or could be used as spamming hosts on the Internet. Here is an explanation of how the GWIA utilizes RBLs:

  1. HostA on the Internet contacts the GWIA and asks for an SMTP session.

  2. The GWIA determines the IP address of HostA.

  3. The GWIA queries its own DNS server for the reversed IP address of the sender appended to the blacklist server's DNS name. For example, if your GWIA was configured to use the blacklist server of BL.SPAMCOP.NET and if the IP address of HostA were 134.55.65.213, the DNS query would look like this:

    213.65.55.134.bl.spamcop.net

If the DNS system does not return a response to the request for the reversed IP address, that indicates to the GWIA that the address is not on that specific blacklist.

If a response for the DNS request is returned, the GWIA knows that the host has been blacklisted.

What's clever about this architecture is that it does not require any special configuration of your local DNS server. This makes RBL checking compatible with virtually any DNS system.

To enable blacklists on your GWIA, you must go to the Blacklists property page under the Access Control tab of the GWIA object in ConsoleOne. Click the Add button, and add the correct host for a blacklistfor example, BL.SPAMCOP.NET, as shown in Figure 25.2.

Figure 25.2. A configured RBL

[View full size image]

You can configure your own blacklist entries and "whitelist" entries if need be. On the Access Control tab on the GWIA object, if you select the Settings property page, you can edit the Default Class of Service profile. When you do so, there are two entry areasone is titled Allow Messages From and the other is titled Prevent Messages From. In this area you can indicate Internet domains that you do not want messages from. In the example shown in Figure 25.3, the GWIA has been configured to reject messages from the Internet domains named spamrus.com and micromonopolysoft.com. The bob@deals.com domain cannot send messages, and the SMTP host at 131.107.3.124 cannot send into the GWIA.

Figure 25.3. Configuring custom blacklists and whitelists

[View full size image]

The Internet host acme.com was blacklisted by SPAMCOP accidentally. ACME is in the process of getting itself off the blacklist, and in the meantime the WorldWide Widgets administrator added acme.com to the whitelistwhich is the Allow Messages From field. This allows the GWIA to accept messages from acme.com even though it's blacklisted at the moment.

An important thing to note here is that you can override entries that your RBL hosts are saying should be blacklisted. You do this by creating an entry for the Internet domain in the Allow Messages From box.

Our Experience with Blacklists

RBL filters are easy to configure and can be part of your spam solution. However, in our own testing in a live customer environment, only about 1 in every 800 spam messages was caught by the spam RBL that we configured, which was caught via DNS queries to bl.spamcop.net. We had a spam solution in place that scanned for words that meant the message was spam after the messages came into the GWIA. Although the GWIA was doing RBL lookups on the messages, the GWIA in conjunction with SPAMCOP was able to detect only a small fraction of the messages that were spam. One thing to note, however, is that you can subscribe to multiple RBL servers. You will need to do your own research to determine which RBL services work the best for you. There are also free RBL services, as well as subscription RBL services available for use.

Implementing Client/Mailbox-Based Spam Solutions

The capability for users to filter unwanted mail within their mailbox is built into the GroupWise client. It's called the "Junk Mail" folder, not the spam folder. For the sake of this discussion, let's classify two kinds of unwanted mailspam and junk mail. Spammers send spam mail, and they generally do so from random bogus Internet email addresses and/or Internet domains. It's generally useless for users to use the junk mail feature in the GroupWise client in an effort to prevent these kinds of messages. They will never get a message from that spammer again, with the same email address or Internet domain. If GroupWise users do use the junk mail feature in GroupWise on spam messages, they are really creating more processing overhead on the POA for no good reason. The cumulative effect of hundreds of users on a large post office using the junk mail feature with hundreds (maybe thousands) of junk mail filters in each user database will drag the POA down over time.

Junk mail is a different kind of a message. Junk mail is when you go to a store, such as Sears, and you give them your email address. Suddenly you start getting weekly mail messages from Sears. With the junk mail feature you can identify weeklyoffers@sears.com as a user whose messages you consider junk mail. This is the kind of scenario that best fits the junk mail feature in the GroupWise client.

You can control the junk mail feature from ConsoleOne, and perhaps even take the feature away from users. We are of the personal opinion that you should not enable this feature for users unless you have implemented a solution at your SMTP entry point or even at the domain or post-office level that first filters out spam. We already established that spammers rarely use the same identity. So if you have not implemented a spam solution prior to the messages getting to the user's mailbox, don't allow them to flag the spam using the junk mail feature. Perhaps the feature will make the user feel good, but in general this feature does not do anything for spam mail; but it does drag down the POA needlessly. The junk mail feature should be used for junk mail, not for spam.

To disable the junk mail feature, you can do the following:

1. | In ConsoleOne, highlight a GroupWise domain.
2. | Select Tools, GroupWise Utilities, Client Options.
3. | Select Environment and uncheck the Enable Junk Mail Handling setting.
4. | Click the padlock to the right of this setting, which will make this setting apply to all post offices under the domain.
5. | Perform this action on all domains in your GroupWise system.

Figure 25.4 shows junk mail handling disabled.

Figure 25.4. Disabling junk mail handling is done through Client Options in ConsoleOne

After you have implemented a server-based spam solution, whether it is SMTP-based or domain- or post office-based, and you are comfortable that the spam solution is filtering out about 95% of your spam, only then should you enable the junk mail handling feature.

It is important to note that junk mail handling is an option only for mail that comes in through your GWIA. Users are not able to "junk" mail that they receive from internal sources. The way that the POA knows whether the mail came through the GWIA is if the view name on the message is Internet. There might be a few customers out there who have changed the view name for inbound Internet messages. You can find out what the view name is for your inbound Internet messages by looking in the GWIA.CFG file for your inbound GWIA(s). Look for the section that says

/MailView-Internet

If your /MailView- switch says something other than Internet, users will not be able to use the junk mailing feature at the client.

So how does the POA process junk mail? The POA will perform several checks on the message to determine whether it matches settings that the user defined through junk mail handling. The POA uses the following algorithm to determine whether a particular Internet message should be junked or blocked based on the user's junk mail settings:

  1. The POA looks for the sender's UserID to determine whether it's on the junk list or block list. If this field is not found, the POA will combine the sender's UserID field with the sender's Internet domain field and check both of these for a match.

  2. Next, it examines the FROM_TEXT field and looks up that address in the junk or block lists.

    If no matches are found, the POA continues by looking for the domain name in the junk and block lists.

  3. The POA checks the contents of the sender's Internet domain field against the spam lists. It also checks shorter versions of the domain name by trimming off the left portions of the name and trying each shortened name until there are only two segments left in the name.

For example, if the IDOMAIN was pinball.games.microsoft.com, the spam checker would first search for pinball.games.microsoft.com, and then for games.microsoft.com, followed by microsoft.com.

The spam checker tries to be fairly robust, checking all the versions of the address it can get its hands on.

You should be aware that there are limitations to the Junk, Block, and Trust lists that are integral with junk mail handling. None of the lists can have more than 1,000 addresses. So you can have up to 1,000 addresses in the Junk List, 1,000 addresses in the Block List, and 1,000 addresses in the Trust List. Furthermore, there is another limit. Of the 1,000 addresses in any of the three lists mentioned, no more than 500 Internet domains can be represented in a list.

Using X-Spam Headers with the Junk Mail Folder

The GroupWise 7 GWIA can be configured to act on X-spam headers. As such, if a message has an X-spam header that matches the X-spam headers that you define on the GWIA, the message will be routed to the recipient's Junk Mail folder. Here's how X-spam headers work:

  1. A message comes in from the Internet to a spam-enabled appliance or solution.

  2. The spam solution determines that the item is spam, and adds an X-spam header to the received SMTP message; for example: X-SPAM:YES.

  3. The spam solution sends the message into the GWIA.

  4. The GWIA reads the X-spam header, and compares the syntax of the header with the X-spam header examples in its xspam.cfg file.

  5. Assuming that the syntax of the X-spam header matches the syntax with a line in the xspam.cfg file, the GWIA flags the message as a Junk Mail item.

  6. When the message is delivered to the recipient's post office, the message is automatically moved to the recipient's Junk Mail folder.

The whole X-spam solution requires that you have some other solution in place that will flag a message as X-spam. The GWIA has no logic that enables it to determine that a message is actually spam. Some other entity must add the X-spam header. GWAVA 3.x has X-spam logic, and other solutions also exist.

To configure the GWIA's X-spam features, you edit the GWIA object in ConsoleOne and add X-spam header lines from the Junk Mail page. This will create the xspam.cfg file in the domain\wpgate\gwia directory. Each line of the xspam.cfg file identifies an "X" header field that your antispam service is writing to the MIME header, along with the values that flag the message as spam. The Internet Agent examines the MIME header for any field listed in the xspam.cfg file. When a match occurs, the message is marked for handling by the GroupWise client junk mail handling feature. The configuration option in ConsoleOne is shown in Figure 25.5.

Figure 25.5. Defining the X-spam headers that the GWIA should look for

[View full size image]


Summary

This chapter explained ways for handling spam and junk mail. GroupWise has some strong built-in junk mail handling features. If you are serious about handling spam, though, you must turn to a third-party solution of some sort.


Chapter 26. Configuring GroupWise Authentication via LDAP

GroupWise client authentication can be configured to use an LDAP (Lightweight Directory Access Protocol) directory as the authentication method for accessing a GroupWise mailbox. The LDAP protocol is a means for getting information from a "directory" type database. In the case of GroupWise, LDAP is used for login credential information so that users can authenticate to GroupWise and access their mailboxes.

This chapter shows you how to configure GroupWise post offices to use LDAP authentication for Novell's eDirectory.


Understanding the Value of LDAP Authentication

For users to access their mailboxes, they need to use authentication credentials. In GroupWise the authentication credentials consist of the USERID/Mailbox ID and a password.

Here are the three most common conditions under which users do not need to enter a password in order to access their GroupWise mailboxes via the Windows client:

  • The user has the Novell client installed, and is authenticated to eDirectory on a Windows computer.

  • The post office security level is set to Low.

  • Novell's SecureLogin/Single Sign-On software is deployed, and so users must enter their GroupWise passwords just once, and Single Sign-On stores the GroupWise password.

Although with the GroupWise Windows client it might be easy to bypass the need to know, or even to create a GroupWise password, there are other circumstances that require the users to enter a password as part of their authentication credentials. These are some of the common circumstances:

  • The Novell client is not installed on a user's computer, and the post office security level is set to High. Some customers are implementing environments in which core "NetWare" services are provided via iFolder and iPrint, and so they do not have the Novell client installed.

  • The user needs to authenticate as a GroupWise WebAccess user.

  • The user needs to authenticate as a GroupWise wireless user.

Without LDAP enabled, a user's password is a GroupWise password, which doesn't necessarily correlate with the user's eDirectory password. The downside to this is that users must then remember two passwords, one for eDirectory and one for GroupWise. This can be particularly confusing for users who regularly use the GroupWise Windows clientwhereby they really do not need to know a GroupWise password. Users are faced with a GroupWise WebAccess login page, and they are dumbfounded as to why the password they enterwhich is their eDirectory passworddoes not allow them to access GroupWise WebAccess.

With LDAP authentication enabled, users can now use their eDirectory password to authenticate to GroupWise. They do not need to remember a GroupWise password; they need to remember only their LDAP or eDirectory passwords for authenticating to GroupWise. There are some other potential benefits to GroupWise using LDAP for authentication credentials, as mentioned here:

  • eDirectory password expiration capabilities will also affect GroupWise (you can control this feature if you want).

  • When a user changes his password in GroupWise, it can also change his eDirectory password (you can control this feature if you want).

Note

Most GroupWise customers will probably be using eDirectory's LDAP component to provide LDAP authentication services to the post office. However, GroupWise is flexible enough to allow you to use LDAP-compliant directories other than eDirectory.


LDAP Authentication and GroupWise External Entities

Before going further, let's quickly address a special class of GroupWise users. GroupWise has a special kind of GroupWise object called a GroupWise external entity. An external entity is a full-blown GroupWise account that has an eDirectory object, but the object class is a GroupWise external entity and not an eDirectory user object. This kind of a GroupWise account cannot authenticate to eDirectory. The reason for this is that these types of users do not have "real" eDirectory user objects. They have a placeholder in eDirectory, but this object is far from a full eDirectory user class object. These users will still use a GroupWise password to authenticate. Enabling LDAP authentication will not break authentication for users who are external entities.

How LDAP Authentication Works

What follows is a high-level explanation of how GroupWise uses LDAP authentication to allow users to access their GroupWise mailboxes:

  • GroupWise user loads the GW client (Windows, WebAccess, wireless, or other).

  • The user sends his or her user ID and password to the post office agent (POA).

  • The POA uses the LDAP protocol to query an external LDAP service provided database.

  • The LDAP requires a login or authentication.

  • The POA validates user credentials against the LDAP provided database.

  • The POA denies or grants access to the user depending on LDAP validation.

As explained in this section, it's important to note that the LDAP authentication logic is all in the POA.

How to Configure LDAP Authentication

The following is a high-level explanation of how to configure LDAP authentication to GroupWise:

  • Define the LDAP server(s).

  • Modify post office security.

  • Set the security level to High.

  • Configure LDAP server settings.

Step-by-Step Instructions for Enabling LDAP Authentication

Now roll up your sleeves; you are going to enable LDAP authentication. When you actually set up LDAP authentication in your system, it's a good idea to do so using a test post office and a few test users at first. This way, you can get familiar with the process of enabling LDAP prior to affecting your live GroupWise system.

Educate Users

When you are ready to cut over to LDAP authentication, educate your users about the fact that they now must use their eDirectory passwords instead of their GroupWise passwords.

In the following scenario, you are going to enable LDAP authentication for a post office called CORPPO on the CORP domain in the WorldWide Widget's GroupWise system.

Define the LDAP Server

Use these steps to define an LDAP server in the GroupWise system:

1. | Load ConsoleOne, and connect to the primary domain. From the Tools menu select GroupWise System Operations, LDAP Servers.
2. | In the Configure LDAP Servers menu, you might see an existing LDAP server. For example, in the WorldWide Widgets system, there is already an LDAP server defined called LDAP CORP CORPPO. The GroupWise snap-ins create LDAP server definitions for new GroupWise post offices. However, if you have upgraded your system from a prior version of GroupWise, you might not have any LDAP servers defined in this dialog box.
3. | Delete the existing LDAP server. In the WorldWide Widgets system, we will use a naming convention such as LDAP1. This naming convention is more logical for the LDAP pooling architecture, which is explained later in this chapter in the section "LDAP Server Pooling."
4. | For ease of configuration, the LDAP servers should be generic in nature, meaning that each post office should not have its own LDAP server defined for that post office, so the name of the LDAP server should not correlate with the name of the post office. In the case of WorldWide Widgets, the name of the LDAP server is LDAP1. Tip The name of the LDAP server must comply with the GroupWise domain naming standards. For example, you cannot use characters such as periods or commas.
5. | Give the LDAP server a description; this can be the same description as the name of the LDAP server.
6. | The next field is the Use SSL field. We strongly encourage you to enable SSL. Do so after you have tested this entire solution in a testing environment, without SSL. The complete instructions for enabling SSL are in Chapter 27, "Securing Your GroupWise System via SSL."
7. | Fill in the LDAP server address, and keep the port of 389. When you enable SSL, the port will be 636.
8. | Choose the user authentication method. Most customers will want to use Bind over Compare. These two methods are explained just a little later, in the section "LDAP Bind and LDAP Compare."
9. | Click the Select Post Offices button, and select the CORPPO post office. Only the CORPPO post office should use this LDAP server.

The LDAP server you have configured should look similar to the one shown in Figure 26.1.

Figure 26.1. LDAP server configuration

[View full size image]

LDAP Bind and LDAP Compare

Two user authentication methods are available for adding an LDAP server. Most customers will want to use Bind instead of Compare. Here's a look at each of these two methods:

The Bind method

  • Uses the user ID and password supplied by the client/user to authenticate to the LDAP server.

  • Requires that the POA make a connection to the LDAP server for each user logging in.

  • Supports password expiration.

The Compare method

  • Requires that the POA use the provided user ID and password to authenticate to the LDAP server.

  • Allows the POA to make only one connection to the LDAP server.

  • Does not support password expiration.

Although the Bind method can be a little bit slower than the Compare method, in most cases we do recommend using the Bind method.

Enable LDAP Authentication at the Post Office

Now that the LDAP server is defined, you must enable LDAP authentication on the post office. Here are the steps for doing so:

1.
Edit the properties of the CORPPO post office object (not the POA object below the post office).

2.
From the GroupWise tab, select the Security property page.

3.
The Security level should be set to High. Place a check mark next to the LDAP Authentication option.

Note

If you enable eDirectory authentication and LDAP authentication at the same time, the LDAP authentication is enforced. For example, with both LDAP and eDirectory authentication enabled, if the GroupWise account does not have a password and you are authenticated to the network, you must still enter your LDAP password to gain access to the GroupWise mailbox. We have found that having both eDirectory and LDAP authentication checked has no real advantages over simply using LDAP authentication.

4.
The LDAP User Name field needs to be filled out only if the LDAP server that you defined earlier in this section uses the Compare user authentication mode. Fill out this field if you use LDAP Compare as your user authentication mode. The syntax for this field is as follows:

CN=eDirectory USERID,
Organizational Unit  unless the user is at the root of the tree,
Organization

For example:

CN=LDAPUSER,OU=NY,OU=AMERICAS,O=WWW

The user does not have to be a super user with Admin equivalent rights. The user just must have Browse, Read, and Compare rights throughout the entire eDirectory tree, or at least in the OU or OUs that house the users that are associated with post office you are configuring.

5.
The LDAP Password field is also used only when using the Compare user authentication mode. If you're using Compare user authentication, fill in this field with a password. The password is the password for the user that you used in the LDAP User Name field.

6.
The Disable LDAP Password Changing option is an important one. The default is to allow users to change their passwords within GroupWise, which changes their eDirectory passwords. There's not necessarily any harm done in allowing users to change their eDirectory passwords from GroupWise, unless you are using some other technology that may need to be apprised of eDirectory passwords. When a password changes in a GroupWise client, there might not be a way for other software to know of that password change. The needs of your environment will dictate whether you want to check the Disable LDAP Password Changing option. Make your decision and select the choice if needed.

7.
The LDAP Pool Server Reset Timeout option has to do with the LDAP server pooling option, which is explained later in this chapter.

8.
Click the Select Servers button and make sure that the LDAP1 LDAP server is in the Selected Servers column.

Figure 26.2 shows the CORPPO's Security property page with LDAP authentication enabled for the post office. The post office supports Bind user authentication mode, and users can change their eDirectory passwords from within a GroupWise client.

Figure 26.2. A post office with LDAP authentication configured

[View full size image]


eDirectory LDAP Server Tips

Although this isn't an eDirectory book, the following section provides a few tips for enabling LDAP on a NetWare or Linux server just the same:

  • The NetWare server you have configured to service LDAP requests must have the module NLDAP.NLM loaded.

  • The Linux server you have configured to service LDAP requests must be running the NDS daemon ndsd. By default, with eDirectory on the Linux platform, LDAP is automatically running. So there is generally no special process to run; just make sure that eDirectory is running on the Linux server. The commands to control the eDirectory daemon on a Linux server are as shown here:

    /etc/rc.d/ndsd {start | stop | status | restart | reload}

  • The NetWare or Linux server that services LDAP requests does not need any replicas on it; however, it is ideal that it have a copy of each eDirectory replica for every partition in the tree. By having eDirectory replicas for all partitions of the tree, the LDAP requests are serviced more quickly.

  • The LDAP server must allow clear-text passwords. By default, eDirectory's LDAP Group object is not configured to allow clear-text passwords. You will encrypt those clear-text passwords when you enable SSL, so there's no harm to do this at this point. Remember, this setting is not enabled as the default, so you are going to need to check it.

The following instructions for confirming that you have the Allow Clear Text Passwords option enabled assume that you have the LDAP snap-ins to ConsoleOne installed:

  1. To confirm that your LDAP server supports clear-text passwords, edit the object in your eDirectory tree called LDAP Group - Server Name. For example, in the WorldWide Widgets Tree, the object is called LDAP Group WWWFS1, and this object is in the same OU as the server called WWWFS1.

  2. Edit the properties of the LDAP Group object. On the LDAP Group General properties page, make sure that the Allow Clear Text Passwords option is checked.

    If you do not have the correct Snap-ins to ConsoleOne, you may not have a General properties page. If this is the case, go to the Other property page and do the following:

    1. Highlight the attribute titled LDAP Allow Clear Text Password.

    2. Click the Modify button, and change the value to TRue.

    3. Click the Apply button.

Note

If you enable the clear-text option, you generally do not need to unload and reload the eDirectory LDAP services. They will detect the changes in configuration, and update dynamically.

That's all that you need to do from an LDAP perspective on the eDirectory platform. You should, of course, make sure that your eDirectory tree is healthy, and available 100% of the time.


Testing and Confirming LDAP Authentication

After you've configured everything, the easiest way to test the LDAP authentication is to do the following:

  1. Create a test user on the CORPPO post office who has LDAP authentication enabled.

  2. Go to the GroupWise Account property page for this user.

  3. Click the Change GroupWise Password button. Change the password to something like 123.

  4. Now change the user's eDirectory password on the RestrictionsPassword Restrictions property page. Make the password abc.

  5. Now try to log into GroupWise as the user. When asked for the password, type abc. If you are allowed in using the eDirectory password, you know that LDAP authentication is working. If you cannot log in, you must troubleshoot the issue. See the next section for LDAP authentication troubleshooting tips.

Now you have configured the basics of an LDAP authentication infrastructure for a GroupWise post office.


LDAP Authentication Troubleshooting Tips

The GroupWise POA will log each time it attempts to authenticate a user to the LDAP server. Make sure that the POA is on Verbose logging; Verbose logging shows you the POA user-authentication process. Figure 26.3 shows the user TKRATZER logging in, and the POA binding to the LDAP server at the IP address 137.65.55.211.

Figure 26.3. A POA log during LDAP authentication

[View full size image]

The POA's log is going to be one of your best mechanisms for troubleshooting LDAP authentication. Some of the things to check include the following:

  • Does the POA seem to have LDAP authentication enabled? If not, rebuild the WPHOST.DB for the post office.

  • Is the server that is supposed to service LDAP requests running the NLDAP module?

  • Is the server that is supposed to service LDAP listening on port 389? Confirm this, with TCPCON on NetWare and netstat na on the Linux platform.

  • If the server is listening on port 389, are you sure it is eDirectory that is listening? If the server is also running the GroupWise GWIA, the GWIA may be listening on port 389. Or perhaps some other LDAP service is running.

  • Does the user you are authenticating as have an eDirectory account? Is the user's GroupWise object grafted to that eDirectory account?

  • Are there eDirectory problems that prevent the server running the NLDAP server from receiving information about the object? Perhaps using DSTRACE with LDAP filters will help to shake out this kind of a problem.

  • Perhaps you need to restart the LDAP services of eDirectory. For example:

    On NetWare:

    unload nldap
nldap

    On Linux:

    /etc/rc.d/ndsd restart

There is a great Technical Information Document in Novell's Knowledgebase at http://support.novell.com. This document explains common LDAP errors in conjunction with the GroupWise POA. Search for the TID # 10067376 in the Knowledgebase search field.


Creating Fault Tolerance

Although LDAP authentication is a great authentication method, if you don't take measures to make it fault tolerant, your users can all be locked out of their GroupWise accounts. If the LDAP server you have configured for your user authentication goes down, the POA cannot authenticate users, and so users will not be able to access their mailboxes. The solution to this potential problem is called LDAP server pooling. The next section talks about how to enable LDAP server pooling.

LDAP Server Pooling

LDAP pooling allows you to define a second (or even a third) LDAP server for the POA to roll over to if the first one is not available for some reason. Here are the steps for doing this:

1.
Create a new LDAP server under Tools, GroupWise System Operations, LDAP Servers, just as you did earlier in this chapter.

Take care to give the name of the LDAP server something slightly different from that of the first LDAP server you defined. For example, to be consistent with the naming standards at WorldWide Widgets, the second LDAP server is called LDAP2.

The IP address (or DNS address) should be different from that of the first LDAP server, because, of course, you want this to be a totally different server just in case the server defined as the first LDAP server goes down or is not available to service LDAP requests.

Be sure to add the CORPPO as one of the post offices that can use the LDAP2 server definition.

2.
Edit the post office object, and go to the Security property page. Click the Select Servers button and be sure to add the second LDAP server to the Selected Servers column, as shown in Figure 26.4.

Figure 26.4. Selecting a second LDAP server

Note

From the Selected Servers column in the Select LDAP Servers dialog box, the order in which the POA will access the LDAP servers is based on the order in which the POA received the update of LDAP servers in its pool. The best way to view the LDAP pool state that the POA knows about is to access the POA's HTTP port. From there, you can click the Configuration tab, and then click the LDAP Authentication link. You will now see all the servers in the LDAP pool, as well as the state of the particular LDAP server. The LDAP server can be in a Starting, Good, or Bad state. Starting simply means that the POA has not really started to talk to this LDAP server. Good means that the POA has contacted this LDAP server, and Bad means that the LDAP server is currently down. If an LDAP server is in the Bad state, you will see a second counter that lets you know when the POA will refresh this LDAP server to see whether its LDAP services are available again.

3.
The LDAP Pool Server Reset Timeout value on the post office's Security property page governs how long an LDAP server is kept out of the LDAP server pool when the POA has determined it cannot obtain services from that LDAP server. You can adjust this setting to your liking; we prefer the default of five minutes.

Other LDAP Authentication Options

Let's take a deeper look at LDAP authentication in order to make an important point. The GroupWise POA identifies the user who is logging in based on the User ID the user fills in via the GroupWise client (be it the Windows, WebAccess, or wireless clients). In every user's record in the GroupWise directory (WPDOMAIN.DB and WPHOST.DB), there is a field called Network ID. There's another field that identifies the eDirectory tree the user is grafted into. These two values come from eDirectory based on the eDirectory object that the GroupWise account is associated with. The POA uses these values to indicate which eDirectory context to look into in order to authenticate the users.

Now that you understand the architecture, imagine that either your LDAP server is in another eDirectory tree, or your LDAP server isn't even a Novell eDirectory LDAP server. What do you do then? You have two options, as discussed next.

Option 1

Each user object has a field on the GroupWise Account page called LDAP Authentication. This field allows you to indicate a different context or fully distinguished name. For example, you could enter this:

CN=ECORNISH,OU=EMPLOYEES,O=FLATTREEORGANIZATION

The fact that you enter the location for the user in another tree means that the LDAP server defined to service this post office must also be in the other tree or LDAP directory.

Option 2

Leave the LDAP Authentication field blank, and make sure that the email address attribute in the LDAP directory matches the eDirectory's email attribute of the GroupWise user. You must then rename the LDAPX.NLM file found on the server where your POA is running and restart the POA. When you perform this step, the POA will not try to look up the eDirectory's distinguished name for the user, and because the LDAP Authentication field is blank, the POA will simply search against the LDAP server for the user's email address. If it finds an email address, it will then know the user's distinguished name, and will know how to authenticate to the other tree or LDAP directory as the correct user.

If you happen to have a workforce tree (an eDirectory tree created from another eDirectory tree via DirXML), and you want to use the workforce tree for LDAP authentication, refer to a Technical Information Document in Novell's Knowledgebase at http://support.novell.com. Search for the TID # 10067272 in the Knowledgebase search field.

This Technical Information Document talks about the details surrounding option 2. External eDirectory trees and DirXML are outside the scope of this book.

We have also used the LDAP Authentication field to associate the user's login credentials with a different eDirectory user object. For example, we wanted to have the user TKRATZER to authenticate with the user ADMIN's password. Here's what we did:

  1. Edited the object TKRATZER.

  2. Went to the GroupWise Account page for TKRATZER.

  3. Entered the following in the LDAP Authentication field:

    CN=admin,O=americas

  4. Now when tkratzer logs into GroupWise, he types TKRATZER as the user ID, and the password for the object ADMIN.AMERICAS in the password field.

So, why do this? We did it to prove it could be done. You'll have to think of under what conditions you might find this useful.


Summary

This chapter explained the benefits derived from GroupWise using LDAP authentication. This chapter also gave step-by-step instructions for enabling LDAP authentication for a post office.

Chapter 27 discusses enabling SSL for LDAP authentication.


Chapter 27. Securing Your GroupWise System via SSL

Every piece of a GroupWise system and a GroupWise messenger system can be secured via SSL (Secure Sockets Layer). SSL allows data to be secured via an industry-recognized protocol for encrypting data between two network hosts.

SSL is used only to encrypt data while it's "on the wire." SSL is not used to encrypt data after it has traversed the network and is on a storage device such as a server or computer hard drive.

GroupWise has always used a proprietary 40-bit encryption scheme. In addition to that, GroupWise not only encrypts the data, but also compresses it using another proprietary scheme. With the advent of government regulations and industry demands, GroupWise supports SSL using 128-bit encryption. Setting up SSL encryption isn't all that difficult, it's just a matter of understanding some underlying concepts really well. You can then apply those concepts in a multitude of areas.

Tip

Using SSL to connect a laptop with a cached mailbox to a post office can be very interesting, because the security of the connection between this client and the PO is as good as many other solutions. In many cases, thanks to SSL you may no longer need to use VPNs to connect your remote or caching clients to your GroupWise environment.


Understanding SSL Architecture

As an administrator, make sure that you read this section thoroughly; it's critical for you to understand how to enable SSL on your GroupWise system. In the following subsection, we're going to give a very simplistic explanation of the pieces of SSL architecture pertinent to understanding how to logically set up SSL encryption in your GroupWise system.

SSL Encryption Using a Symmetric Key Method

The symmetric key method for encrypting data via SSL is one in which the hosts that communicate use the same encryption key. Security of the encrypted data between the two hosts is assured only if the encryption key is secret. In a GroupWise environment there is one scenario in which a symmetric key is used for SSL-izing data. The WebAccess Application to WebAccess Agent communication uses a symmetric key held in the COMMGR.CFG file. The key is editable via ConsoleOne. See Chapter 11, "Installing and Configuring GroupWise WebAccess," for more details about the COMMGR.CFG file.

SSL Encryption Using Public Key Infrastructure (PKI)

SSL uses two types of keys in combination with one another:

  • Public keys

  • Private keys

These keys allow Internet hosts to encrypt and decrypt data that will be sent to one another. If HostA wants to send encrypted data to HostB, HostA must obtain HostB's public key. Using HostB's public key, HostA encrypts its data to HostB. HostB uses its private key to decrypt the data. The same goes for how HostB sends encrypted data to HostA. HostB uses HostA's public key to encrypt data going to HostA. HostA then decrypts the data using its private key.

A public key must be signed by a certificate authority (CA). After a public key is signed, it is considered a certificate. The private key is still considered a private key, or just the key.

A certificate simply says that the public and private keys of HostA are certified by HostZ. HostZ is considered the certificate authority. HostB makes the decision as to whether to trust the certificate authority. If it does, the certificate for HostA is considered valid. HostB can send data using HostA's public key, with confidence that only HostA knows HostA's private key.

A certificate can also be self-signed, which means that the host that creates the certificate also signs the certificate. A self-signed certificate is generally used for encryption when two hosts have already established a trusted relationship with one another, and they simply need to use public and private keys to encrypt and decrypt data. The GroupWise client and the GroupWise Messenger clients both use self-signed certificates for communicating with their supporting agents.

Public Key Infrastructure and a Novell Environment

With Novell's eDirectory software fully implemented, the pieces of PKI that are relevant to this discussion are already in place. They are listed here:

  • The certificate authority: All eDirectory trees version 8.x or better have a certificate authority. Figure 27.1 shows the certificate authority in the WorldWide Widgets tree. The certificate authority (CA) in your Novell eDirectory tree can sign the public keys, which will validate the key.

    Figure 27.1. The certificate authority in an eDirectory tree

    [View full size image]

  • Public Key Generation: With Novell's Certificate Server and Certificate Server snap-ins in place, you can submit a private key. Certificate Server can generate a public key to be used in companion with the private key.


Configuring and Signing Certificates in eDirectory

This section assumes you have the following prerequisites:

  • eDirectory 8.6.2 or better

  • GroupWise 7

There are other prerequisites to fulfill in order to create signed keys (certificates), but the next subsection explains how to fulfill those prerequisites.

Administrator's Workstation Prerequisites

The following are prerequisites for one administrator's workstation. Not everyone who uses ConsoleOne, or who is a network administrator, must have these prerequisites fulfilled. The following subsections are presented as though the administrator is using Windows.

Workstation NICI

Install the Novell International Cryptographic Infrastructure for Windows. At the time that this book was written, these are the instructions for doing this:

  1. Go to http://download.novell.com and look for "NICI," which is short for Novell International Cryptographic Infrastructure. At the time that this book was written, the name of the file to download was wcniciu0.exe. This software will be installed directly on the machine from which you are going to use ConsoleOne. This software is necessary for the Novell Certificate Server snap-in, which you will install later, to work.

  2. Run the *.EXE that you pulled down, and follow the installation wizard.

NICI is now installed, and the workstation does not even need to be rebooted for NICI to take effect.

Novell Certificate Console (PKI) Snap-ins for ConsoleOne

Although you have a CA and a PKI infrastructure already in place, it's possible that you do not have the Novell Certificate Console (PKI) snap-ins for ConsoleOne installed. The easiest way to determine what is installed is to load ConsoleOne, and select Help, About Snapins. You need to make sure you have the Novell Certificate Server Snapin Version 2.21 or better. If you do not have these snap-ins, obtain them from Novell's website and install them. Here are instructions for doing that, at the time this book was written:

  1. Go to http://download.novell.com.

  2. Obtain the latest Certificate Server PKI snap-ins for ConsoleOne by selecting it from the list. At the time this book was written, the software was called "2.21 Snap-in on Windows 95/98/NT/2000." The snap-ins were available as a download under the category "ConsoleOne."

  3. This software does not have a README or an install routine. To install this software, run your UNZIP utility to expand the zipped file. When prompted for a path to expand the software, indicate the path to ConsoleOne, such as C:\NOVELL\CONSOLEONE\1.2. Be sure to indicate the full path to the 1.2 directory. Figure 27.2 shows PKUNZIP with the correct extract path.

    Figure 27.2. Installing the PKI snap-ins for ConsoleOne

The PKI snap-ins for ConsoleOne will now load when ConsoleOne loads. These snap-ins will aid in the creation of certificates.

Generating a Private Key and a Certificate Signing Request for the Private Key

GroupWise comes with a utility (GWCSRGEN.EXE) that can create a private key in the form of a file, and a CSR (certificate signing request) for that private key. Then the private key can be signed by an external certificate authority such as Verisign, or the certificate can be signed by the certificate authority in your eDirectory tree. This chapter assumes you will have the key signed by the certificate authority in your eDirectory tree.

You can find GWCSRGEN.EXE in the GroupWise 7 SDD\ADMIN\UTILITY\GWCSRGEN directory.

Following are the steps for using the GroupWise CSR Generate utility:

1.
Run the GroupWise CSR Generate utility.

2.
Fill in the fields of the CSR Generate utility, as shown in Table 27.1.

Table 27.1. GroupWise CSR Generate Utility Configuration Instructions

FIELD NAME

INSTRUCTIONS

Key filename

Name the file with an 8.3 name. The name doesn't matter to the software; we like to use a name with a *.KEY filename; for example, WWWIDGET.KEY.

Key password

This is a password that will be embedded inside the private key. This should be a password you will not forget. If you do, though, you will have to go through this entire procedure again.

CSR filename

The name and length of this file does not matter; it will be used only temporarily. We like to put a *.CSR extension on the file; for example, WWWIDGET.CSR.

Country

The two-letter country code for the country you are in. For example, for the United States the country code is US. For The Netherlands, it's NL.

State/Province

The state or province where your company is located.

City

Your city; you do not need to use abbreviations.

Organization

The full name of your organization; for example, WorldWide Widgets Corporation.

Division

The division of your organization that needs this certificate; for example, ITS.

Hostname of Server

Technically, you define the DNS name for the server that will be using this certificate. However, in this example we will use the same certificate on all the agents, and in fact the DNS name need not be valid for GroupWise to use the certificates for encryption. You can just use the Internet domain name for your organization; for example, WWWIDGETS.COM.

Figure 27.3 shows the GroupWise CSR Generate utility with the aforementioned settings.

Figure 27.3. The GroupWise CSR Generate utility is used to create a private key and generate a certificate signing request

[View full size image]

Generating a Public Key from the Certificate Signing Request

Following are the steps for generating a certificate from the CSR you made in the preceding section:

1.
Load ConsoleOne. This must be the same instance of ConsoleOne with the Novell Certificate Server snap-ins.

2.
Highlight any Organizational Unit, or Organization in your eDirectory tree browser view, and select Tools, Issue Certificate.

3.
You should get the Issue Certificate dialog box shown in Figure 27.4. Click the Browse button to the right of the Filename field. Browse to the *.CSR file that you made in the instructions earlier in this chapter, and click Next.

Figure 27.4. Specifying a CSR filename

[View full size image]

4.
At the next page, you don't have any selection to make. Just click Next.

5.
On the next screen, shown in Figure 27.5, you specify the key type. Select the following options and click Next:

Figure 27.5. Specifying key type and usage

[View full size image]

  • Custom

  • Data encipherment

  • Key encipherment

  • Digital signature

6.
At the next screen, you can choose the number of years that the certificate is valid for. Only you will be using these certificates; therefore, you might want to specify a period longer than the default, for example, five years. Then click the Next button.

7.
On the review screen you get to see the configuration options you chose. Click the Finish button.

8.
Lastly, you'll see the Save Certificate dialog box, as shown in Figure 27.6. Make sure to choose Base64 format for the file type.

Figure 27.6. Saving the certificate in Base64 format

Now you have generated and created a public key contained within a certificate which is the *.B64 file, a private *.KEY file. The private key is secured through the password that you assigned to the key when you used the GroupWise CSR Generate utility.

Securing GroupWise Agents That Use Certificates and Key Files

The instructions in the remainder of this chapter ensure that the following data is secured via SSL:

  • GroupWise client to GroupWise POA communication

  • GroupWise WebAccess agent to GroupWise POA communication

  • GroupWise POA to IMAP client communication

  • GroupWise POA to SOAP client communication

  • GroupWise POA to MTA communication via MTP

  • GroupWise MTA to MTA communication via MTP

  • HTTP monitoring of the GroupWise MTA

  • HTTP monitoring of the GroupWise POA

  • HTTP monitoring of the GroupWise WebAccess agent

  • GroupWise Messenger Client to the Novell Messaging Agent

  • GroupWise Messenger Client to the Novell Archive Agent

  • HTTP monitoring of the Novell Messaging Agent

  • HTTP monitoring of the Novell Archive Agent

  • The GWIA's communications with other Internet hosts (that support SSL)

  • The GWIA's communications with POP3 clients

  • The GWIA's communications with IMAP clients

The public key, the private key, and the password for the private key can be used to fill in the fields. In ConsoleOne, you'll see the options to fill in the fields shown in Table 27.2.

Table 27.2. Certificate Creation Configuration Instructions

FIELD

INPUT

Certificate

The *.B64 file; the filename should not exceed the size of an 8.3 character filename.

SSL Key File

The *.KEY file; the filename should not exceed the size of an 8.3 character filename.

Set Password

This is the password you input earlier when using the GroupWise CSR Generate utility to generate the private key.

The path to the *.B64 and the *.KEY files should be a path on the server where the GroupWise agent is running. You have lots of flexibility as to where you place the certificates; it just needs to be somewhere on the server that is running the GroupWise agent. We like to use a model where we create a CERT directory off of the root data directory for that agent. Table 27.3 depicts our method for placing these files.

Table 27.3. Recommended Certificate and Private Key Locations

AGENT

CERTIFICATE AND KEY LOCATION

GroupWise MTA

Create the CERT directory off of the domain directory. The domain directory is the one that contains the file WPDOMAIN.DB.

GroupWise POA

Create the CERT directory off of the post office directory. The post office directory is the one that contains the file WPHOST.DB.

GroupWise WebAccess Agent

Create the CERT directory off of the Domain\WPGATE\WEBACCESS GATEWAY DIRECTORY.

GroupWise Internet Agent

Create the CERT directory off of the Domain\WPGATE\GWIA GATEWAY DIRECTORY.

Novell Messenger/GroupWise MessengerMessaging Agent

Create the CERT directory off of the SYS:NOVELL\NM\MA directory.

Novell Messenger/GroupWise MessengerArchive Agent

Create the CERT directory off of the SYS:NOVELL\NM\AA directory.

This method of placing the key and certificate under the root data directory for the agent is friendly to scenarios in which Novell Cluster Services is in place. Also, when you have the key and certificate files in close proximity to the root data directories of your agents, other folks with administrative rights to your servers are less likely to mess with these files because of their proximity to your GroupWise system's data directories. Figure 27.7 shows a GroupWise POA that has been configured to use a public and private key, and the password for the private key on the SSL Settings property page of the POA object. The password you use is the same one used when generating the private key in the GWCSRGEN.EXE utility.

Figure 27.7. A configured SSL Settings property page for a GroupWise POA

[View full size image]

Filling out the SSL Settings property page of a GroupWise agent is not all you must do to enable SSL. You must also enable SSL encryption for the services that the agent provides. For example, on the GroupWise POA, you might enable SSL encryption for client/server connections, MTP communication, and HTTP monitoring. Figure 27.8 shows a POA configured for these settings.

Figure 27.8. Specifying SSL for services the POA provides

[View full size image]

It's important to note that for some of the SSL fields on the POA you can set SSL to Disabled, Enabled, and Required. The Required option has the following impact. Suppose the POA is set for SSL Required for Local Intranet Client/Server. If a GroupWise WebAccess agent or client does not support SSL, that agent or client cannot log in to the GroupWise POA. Note that the only GroupWise clients that support SSL are the GroupWise 6.5 and GroupWise 7 clients. The GroupWise 5.x and 6.0x clients do not support SSL.

When a GroupWise client/server session is SSL-ized, a little padlock icon shows up in the lower-right corner of the GroupWise client. If a user hovers over the padlock with the mouse pointer, a simple dialog box displays that reads SSL Secured, as shown in Figure 27.9.

Figure 27.9. A GroupWise client/server session secured by SSL

[View full size image]

The location for configuring SSL certificates and keys is similar for all GroupWise agents. The GroupWise Messenger/Novell Messenger agents are slightly different. Table 27.4 lists the agent type, explains where to configure the SSL certificates and keys, and indicates where to configure the services that are SSL-ized by that agent.

Table 27.4. How to Configure GroupWise Agents to use SSL

AGENT TYPE

WHERE TO CONFIGURE SSL

WHERE TO CONFIGURE SERVICES

Agent

SSL certificate and key configuration

SSL enabling services for this agent

POA

SSL Settings property page under the GroupWise tab

Network Address property page under the GroupWise tab

MTA

SSL Settings property page under the GroupWise tab

Network Address property page under the GroupWise tab

WebAccess Agent

SSL Settings property page under the GroupWise tab

Network Address property page under the GroupWise tab

GroupWise Internet Agent (GWIA)

SSL Settings property page under the GroupWise tab

Network Address property page under the GroupWise tab

Novell Messenger/GroupWise MessengerMessaging Agent (MA)

Security property page under the Agent tab

Security property page under the Agent tab

Novell Messenger/GroupWise MessengerArchive Agent (AA)

Security property page under the Agent tab

Security property page under the Agent tab

Table 27.5 offers some important notes with regard to SSL-izing the agents.

Table 27.5. Troubleshooting Notes When Enabling SSL on GroupWise Agents

AGENT

NOTES

POA

If you "require" SSL connections, you might end up denying connections to certain clients and WebAccess Agents. After enabling SSL, the POA generally picks up the changes and does not need to be restarted.

MTA

After enabling SSL, the MTA generally picks up the changes and does not need to be restarted.

WebAccess Agent

After enabling SSL, the WebAccess Agent (GWINTER) must be restarted.

GWIA

After enabling SSL, the GWIA must be restarted. The GWIA will only SSL-ize communication with other Internet SMTP hosts that also support the extended SMTP StartTLS protocol. In Chapter 30, the section "Overview of How to Secure Messages" talks more about StartTLS.

Novell Messenger/GroupWise MessengerMessaging Agent (MA)

Be sure to enable the option. Enable SSL for Client/Server. After SSL is enabled, the MA must be restarted.

Novell Messenger/GroupWise MessengerArchive Agent (AA)

Be sure to enable the option. Enable SSL for Client/Server. Be sure to enable the option. Enable SSL for Message Transfer Protocol if the MA and the AA are configured to run on separate servers. After SSL is enabled, the AA must be restarted.

Note

If you need to change the password on the key file, you normally need to restart the agent. Review the Agent log file to see whether it reports that it must be restarted because of a change to the key password.

Enabling SSL for POA to LDAP Server Communication

Chapter 26, "Configuring GroupWise Authentication via LDAP," talks about how to enable the POA to perform LDAP authentication. Be sure to read that chapter first before trying to understand the steps in this section. Also, be sure to read all the material preceding this section so that you'll more fully understand the steps you will be taking in this section.

In a Novell eDirectory environment, the LDAP server by default uses the SSL CertificateDNS server name object in the same context as the server running LDAP services. This object is actually called a key material object. For the GroupWise POA to communicate with the LDAP server via SSL, the POA must use that same encryption key. The Novell LDAP server reads the key right out of eDirectory, but the GroupWise POA does not. The key, therefore, must be exported to a file so that the POA can use it to send encrypted data to the Novell LDAP server. When you configure your GroupWise POA to speak to a specific LDAP server, you must have exported the key file that the LDAP server also uses. Read through this sample scenario to understand how to configure the LDAP server and the POA to talk to one another via SSL.

Note

The server running the GroupWise POA for CORPPO Post Office (WWWFS1) is a NetWare 6.5 server running a GroupWise 7 POA.

Server Hosting Novell LDAP Services (WWWFS2)

There are three basic steps behind enabling SSL communications, as detailed here:

1. | Make sure that your LDAP server is configured to speak correctly when using an SSL connection.
2. | Export the encryption key file for the same key material object in eDirectory that the LDAP server is currently configured to use. This way, the POA can use the same encryption key from the key material object that the LDAP server is currently using.
3. | Configure your POA to use the encryption key you obtained from the LDAP server.

The following sections walk through these actions.

Configuring the LDAP Server to Support SSL

The default settings for an eDirectory LDAP server do not allow for clear-text passwords. If you enabled the LDAP server to allow clear-text passwords, in order to set up and test your LDAP authentication without SSL, this is where you can now disable the option for clear-text passwords. This ensures the security of your eDirectory usernames and passwords because now any service using NLDAP must use encryption to talk to the LDAP server. You should confirm the following configuration settings for the LDAP server:

  • Confirm the port for LDAP SSL communication (which is 636 by default).

  • Confirm that SSL is enabled for the LDAP server.

  • Confirm that the LDAP server does not allow clear-text passwords.

  • Determine which key material object the LDAP server is using.

Here are the steps for checking out these settings. You might not have the correct LDAP server snap-ins, so rather than taking you through the process of obtaining the LDAP server snap-ins, this section instructs you about how to check these settings without the LDAP snap-ins. If you have the LDAP snap-ins for ConsoleOne, the settings we mention should be easy to find:

1.
Highlight the eDirectory OU that contains the server that is running the LDAP services.

2.
Edit the object called LDAP Server server name of the server running LDAP services. In our example scenario this object is called LDAP ServerWWWFS2.

Note

You want to confirm that SSL is enabled for LDAP and that the SSL port is configured to 636. You also need to determine the key material object that the LDAP server is using.

3.
From the Other tab (this is if you do not have the LDAP snap-ins), confirm the following:

  • LDAP Enable SSLExpand this attribute and make sure that it says true.

  • LDAP SSL PortExpand this attribute and determine the port. It should generally read 636.

  • LDAP:keyMaterialNameExpand this attribute, and determine the key that the LDAP server is configured to use. Generally the key is SSL CertificateDNS. If it's not, just make note of which key is being used.

4.
Exit the LDAP server object you have been looking at, and find the object called LDAP Group server name of the server running LDAP services. In this sample scenario, this object is called LDAP GroupWWWFS2.

5.
Edit the LDAP Group object. Go to the Other tab and confirm the setting called LDAP Allow Clear Text Password. Expand this attribute and make sure that it reads false.

Your LDAP server is now prepared to support SSL.

Obtaining a Key File for the SSL CertificateDNS Object

In this section, you need to export a key file for the SSL certificate already in eDirectorywhich the LDAP server is also using. By default, most LDAP servers are configured to use the SSL CertificateDNS server name key material object. If your LDAP server is using a different key material object, just follow the instructions in this section with the appropriate key material object. This object is in the same context as the server, the LDAP server, and LDAP group objects mentioned in the preceding section. In this scenario, the name of the object is SSL CertificateDNSWWWFS2. Follow these steps:

1.
Load ConsoleOne. You must be using the ConsoleOne with the Certificate Server snap-ins.

2.
Highlight the SSL CertificateDNS server name object. In this sample scenario, the name of the object is SSL CertificateDNSWWWFS2. Edit this object.

3.
Select the Certificates tab, and then choose the Trusted Root Certificate property page.

4.
Click the Export button.

5.
In the Export Certificate dialog box, do not export the private key with the certificate. Click the Next button.

6.
In the next export screen, keep the file in *.DER format, and give the file a descriptive 8.3 character format. In the example shown in Figure 27.10, the file is saved as fileservername.DER. Click the Next button.

Figure 27.10. Exporting the public key into *.DER format

[View full size image]

7.
On the summary screen, click the Finish button to export the key.

8.
Copy the *.DER file that you just created to the program directory for the GroupWise POA. On the NetWare Server this is as follows:

SYS:SYSTEM

On a Linux server you put the *.der file in the following directory:

/opt/novell/groupwise/agents/lib/nldap

Configuring the POA to Use the Encryption Key

You are ready to configure the GroupWise LDAP server definition so that it will support SSL. Follow these steps to do so:

1.
In ConsoleOne, find your already-configured LDAP server definition you just exported (the *.DER file). These LDAP server definitions are available under Tools, GroupWise System Operations, LDAP Servers.

2.
Edit the LDAP server, and select the Use SSL check box.

3.
Do not use the Browse button, which indicates a UNC path to the *.DER file. Instead, just indicate the name of the *.DER file only. Because the *.DER file is in the program directory of the POA, the POA will discover it there. Using this method of referencing only the name of the *.DER file then allows the LDAP server definition to be generic in fashion, and usable by other GroupWise POAs. So in the SSL key file field indicate the *.DER file that correlates to the LDAP server whose TCP/IP address is referenced in the LDAP server address field. In this scenario, it's the TCP/IP address for the file server WWWFS2. The *.DER file is WWWFS2.DER, as shown in Figure 27.11.

Figure 27.11. Enabling SSL for LDAP servers in GroupWise system operations

[View full size image]

Note

Remember that with Linux, filenames are case sensitive. If an LDAP server is being used by Linux and NetWare POAs, it is probably best to indicate the name of the *.der file in lowercase.

4.
Change the LDAP port from 389 to port 636. Figure 27.11 shows a configured LDAP server definition.

5.
The POA might need to be restarted for it to acknowledge the SSL settings for LDAP authentication that you just enabled.

6.
Test to see whether LDAP over SSL is working using these benchmarks:

  • Make sure that the GroupWise POA is set to use verbose logging.

  • Log in to GroupWise as a user on the post office where you have LDAP over SSL configured.

  • Observe the log of the POA; you should see something similar to the following sample log:

    13:13:11 1AB C/S Login win Net Id=irina ::GW Id=irina :: 137.65.55.212
13:13:11 1AB Initializing Secured LDAP session
with 137.65.55.211 at port 636 using SSL
Key file SYS:SYSTEM\wwwfs2.der

Now with SSL enabled for LDAP requests, users' passwords will no longer go across the wire in an unencrypted manner.

Enabling SSL for GroupWise Messenger to LDAP Server Communication

The steps to configure the GroupWise Messenger Agent's (MA) communication with the LDAP server over SSL are very similar to those for configuring the GroupWise POA. This section assumes that you already have the MA configured for LDAP authentication. In this section, you are merely enabling SSL.

In a Novell eDirectory environment, the LDAP server uses (by default) the SSL CertificateDNS server name object in the same context as the server running LDAP services. This object is actually called a key material object. For the GroupWise POA to communicate with the LDAP server via SSL, the POA must use that same encryption key. The Novell LDAP server reads the key right out of eDirectory, but the MA does not. The key, therefore, must be exported to a file so that the MA can use the key to send encrypted data to the Novell LDAP server. When you configure your MA to speak to a specific LDAP server, you must have exported the key file that the LDAP server also uses. Read through this sample scenario to understand how to configure both the LDAP server and the MA to talk to one another via SSL.

The server running the Novell Messenger/GroupWise Messenger MA (WWWFS1) is a NetWare 6.5 server running the Messaging Agent.

Server Hosting Novell LDAP Services (WWWFS2)

There are three basic steps behind enabling SSL communications:

1. | Make sure that your LDAP server is configured to speak correctly when using an SSL connection.
2. | Export the encryption key file for the same key material object in eDirectory that the LDAP server is currently configured to use. This way, the MA can use the same encryption key from the key material object that the LDAP server is currently using.
3. | Configure your MA to use the encryption key you obtained from the LDAP server.

The following sections walk through these actions.

Configuring the LDAP Server to Support SSL

The default settings for an eDirectory LDAP server do not allow for clear-text passwords. If you enabled the LDAP server to allow clear-text passwords in order to set up and test your LDAP authentication without SSL, this is where you can now disable the option for clear-text passwords. This ensures the security of your eDirectory usernames and passwords, because any service using NLDAP must use encryption to talk to the LDAP server. You should confirm the following configuration settings for the LDAP server:

  • Confirm the port for LDAP SSL communication (which is 636 by default).

  • Confirm that SSL is enabled for the LDAP server.

  • Confirm that the LDAP server does not allow clear text passwords.

  • Determine which key material object the LDAP server is using.

You might not have the correct LDAP server snap-ins, so rather than taking you through the process of obtaining the LDAP server snap-ins, this section instructs you about how to check these settings without the LDAP snap-ins. If you have the LDAP snap-ins for ConsoleOne, these settings are easy to find. We do not recommend modifying these attributes without the LDAP snap-ins. If you must modify them, you must find a copy of ConsoleOne that has the LDAP snap-ins enabled. Use these steps to view the settings:

1.
Highlight the eDirectory OU that contains the server that is running the LDAP services.

2.
Edit the object called LDAP Server server name of the server running LDAP services. In this sample scenario, this object is called LDAP ServerWWWFS2.

Note

You want to confirm that SSL is enabled for LDAP and that the SSL port is configured to be 636. You also need to determine the key material object that the LDAP server is using.

3.
From the Other tab (this is if you do not have the LDAP snap-ins), confirm the following:

  • LDAP Enable SSLExpand this attribute and make sure that it reads TRue.

  • LDAP SSL PortExpand this attribute and determine the port. It should generally read 636.

  • LDAP:keyMaterialNameExpand this attribute, and determine the key that the LDAP server is configured to use. Generally the key is SSL CertificateDNS. If it's not, just make note of which key is being used.

4.
Exit the LDAP Server object you have been looking at, and find the object called LDAP Group Server name of the server running LDAP services. In this sample scenario, this object is called LDAP GroupWWWFS2.

5.
Edit the LDAP Group object. Go to the Other tab and confirm the setting called LDAP Allow Clear Text Password. Expand it and make sure that it reads false.

Your LDAP server is now prepared to support SSL.

Obtaining a ROOTCERT.DER Key File from a Server Running LDAP

In this section, you need to obtain the ROOTCERT.DER key file from the SYS:PUBLIC directory in which the LDAP services are running. The steps to perform this are the following:

1. | Go to the SYS:PUBLIC directory of the server that is running your LDAP services. Obtain the ROOTCERT.DER file.
2. | Make sure that there is a directory under the MA root directory called CERT. Copy the ROOTCERT.DER file mentioned in step 1 to the CERT directory under the MA root directory.
3. | Rename the ROOTCERT.DER file to something like the fileserver name of the file server running LDAP services.DER. The filename should be in the 8.3 format; for example, WWWFS2.DER.

Now you have put the LDAP server's key file in physical proximity to the GroupWise Messaging Agent so it can use the key file.

Configuring the GroupWise LDAP Server Definition to Support SSL

Following are the steps for enabling LDAP authentication for the GroupWise Messaging Agent:

1.
In ConsoleOne, find your already-configured LDAP profile or profiles if you are using LDAP server pooling. The LDAP profiles are in the LDAPContainer object located under the MessengerService object.

2.
Edit the LDAP profile object that you have already configured.

3.
Under the LDAP Profile tab, go to the Connections Property page.

4.
Edit the connection that represents the LDAP server you have obtained the public key for. Change the port to 636. Enable the SSL Enabled check box.

5.
Use the Browse button next to the Root Certificate File field and select the *.DER file that correlates to the LDAP server whose TCP/IP address is referenced in the LDAP server address field. In this scenario, it's the TCP/IP address for the file server WWWFS2. The *.DER file is WWWFS2.DER, as shown in Figure 27.12. If the path is on a Linux server, indicate the Linux path to the *.DER file and keep in mind case sensitivity on the file.

Figure 27.12. The LDAP Connection window is where you define the LDAP server, as well as the key file associated with it

[View full size image]

6.
The Messaging Agent (MA) must be restarted for it to acknowledge the SSL settings for LDAP authentication that you just enabled.

Now with SSL enabled for LDAP requests and users' passwords, requests to LDAP will no longer go across the wire in an unencrypted manner.


Summary

This chapter reviewed how to enable SSL communication on all GroupWise agents (except the Monitor agent, which cannot be SSL-ized). The encryption strength is 128-bit. In an average Novell environment, the process of enabling SSL is simple and cheapfree in fact!


Chapter 28. Restoring Deleted Users

Did you ever need to restore a deleted user? Maybe you were told to delete a user, you did, and then you were being told to bring the user back. Or maybe you deleted a user by accident. Either way, restoring a deleted user is a not an easy task, so this chapter attempts to give you a complete solution to this problem.

This chapter gives you step-by-step instructions, and it also tries to weave in some architectural explanations about what you are trying to accomplish within the various steps.

To restore a deleted user, you must use the Recover Deleted Account utility, which was new to GroupWise 6.5 and of course is still present in GroupWise 7, or you must import the user. This process brings back only the user's object, not the user's messages. Then you must restore the user's messages. Restoring users' messages is also explained in this chapter.


The Scenario

Tay Kratzer's (TKRATZER) GroupWise account was accidentally deleted. You need to restore everything you possibly can of Tay's email. Tay is on a GroupWise domain called CORP and a post office called CORPPO.

First we'll give a high-level view of the steps you will take. There are two major methods for restoring a deleted user. The simplest method is called Recover and Restore. This method requires that you have a WPDOMAIN.DB file that existed before the user's deletion. The more complex method (and only slightly more thorough) is called Import and Restore or Archive. Following is a high-level explanation of both of these methods.

Recover and Restore

This method uses the Recover Deleted Account utility introduced in GroupWise 6.5; what follows is a high-level discussion about this method of restoring a user:

  • Recover the user's object via the Recover Deleted Account utility.

  • Restore the user's mailbox via the Backup/Restore Mailbox utility.

Import and Restore or Archive

In some cases you might still need to use the older method to import the user and restore the mailbox items manually; following is a high-level discussion about this method of restoring a user:

  • Import TKRATZER with the same USERID, FID, first name, and last name that TKRATZER used before he was deleted.

  • Condition the WPHOST.DB file for Tay's post office so that Tay is a member of the post office, the post office security level is low, the post office supports client/server and direct connections, and WPHOST.DB has a new mailbox password for Tay.

  • Place the WPHOST.DB file in the restored post office's directory, and get into GroupWise.

  • In GroupWise, archive and export as much info as possible.

  • Unarchive and import items into TKRATZER's live mailbox account.

You are welcome to mix and match elements of both of these solutions. For example, you can use the Recover method for re-creating the user's object (rather than the Import method), and then use the Archive method for restoring the user's mailbox. Two tasks must take place: The user's account must be re-created, and the user's messages must be restored. How you accomplish these two tasks is up to you, and GroupWise is flexible enough to accommodate your particular situation.


Recover and Restore a User's Account

Bringing back a deleted user's account is the easier method. All the needed utilities are built into GroupWise 7. If you cannot meet (or easily meet) the prerequisite mentioned in the next subsection, which requires the WPDOMAIN.DB from backup, you will want to proceed to the method called Import and Restore or Archive. The Import and Restore or Archive method covered in the next major section brings back all that this method does, and more. The Recover and Restore method does not bring back the following:

  • Personal address books

  • Items in the Trash folder

  • Rules and proxy settings

If losing personal address books, trash, and the user's rules and proxy settings is not a problem, go ahead and use the methods explained in this section.

Prerequisites

You must have the following two components before getting started:

  • A backup copy of WPDOMAIN.DB for your system's GroupWise primary domain that existed before TKRATZER was deleted. If you do not have this backup copy of the primary domain, you can use a backup copy of any secondary domain that existed before TKRATZER was deleted.

  • A backup copy of the entire CORPPO post office that existed before TKRATZER was deleted.

Bringing the User Back

This section focuses on how to bring the user's eDirectory and GroupWise object back. You must have a backup copy of WPDOMAIN.DB for the system's GroupWise primary domain, as it existed before TKRATZER was deleted. If you don't have it, you can use a backup copy of any secondary domain as it existed before TKRATZER was deleted. The steps to follow are given here:

1.
Load ConsoleOne and connect to the primary domain.

2.
From the Tools menu, select GroupWise Utilities, Recover Deleted Account.

3.
To fill in the Backup Domain Path field, browse to the WPDOMAIN.DB that you brought back from backup.

4.
Click the Account to Restore button, and select the deleted user TKRATZER. Figure 28.1 shows a configured Recover GroupWise Account dialog box.

Figure 28.1. The Recover GroupWise Account Wizard in ConsoleOne

[View full size image]

5.
Click Next, and proceed through the rest of the Recover GroupWise Account Wizard.

6.
After the account is recovered, confirm that the newly restored account can get into the GroupWise mailbox. The user's password is also recovered during this process.

Note

At this time, the account is restored but the messages in the mailbox are not.

Tip

At some sites, we've seen issues when trying to open the mailbox of the recovered account, resulting in C05D errors on the POA console. One solution that sometimes helped was to unload the POA and then load it again, to make sure that the POA flushes all tables. If this doesn't help, take a look in the Knowledgebase at www.support.novell.com; we've found TID 10074228 very useful.

Now the user object should be restored. In our experience, restoring users in the manner explained in this section works most of the time, but not all the time. Don't worry if it does not work; we still have a solution for you in the section "Import and Restore or Archive a User's Account."

Restoring the User's Mailbox

In ConsoleOne you need to set up a restore area where the GroupWise message store of the post office that houses the deleted user can be restored and then accessed by users or the GroupWise POA in order to restore deleted and purged email.

You set up the post office's restore area within the GroupWise System Operations menu in ConsoleOne. Figure 28.2 shows that a restore area has been set up for the CORPPO post office.

Figure 28.2. The Restore Area Directory Management dialog box in ConsoleOne

To set up a restore area, follow these steps:

1. | Load ConsoleOne.
2. | Connect to the primary domain.
3. | From the Tools menu, select GroupWise System Operations, Restore Area Management.
4. | Type the name of the restore area and type a description if you want.
5. | Create the directory structure you plan to use for the restore area. This should be a directory structure on a server that the POA can access. Either enter the UNC path in the restore area or browse to it. For customers accustomed to the restore feature in GroupWise 6.5, it's important to note that the restore area no longer needs to be accessible to users as long as they are using the GroupWise 7 client. Note Make sure that the directory path of the restore area does not include any directory names longer than eight characters, because we've seen issues with longer directory names if the POA needs to recover the messages from this restore area. If the post office is on a Linux server, make sure that the Linux path is specified.
6. | Click the Membership tab to add users (or an entire post office) whose messages need to be restored.
7. | Click Close to create the definition for the restore area. Note If in step 6 you added the post office to the Membership tab of the restore area, you can access the Post Office Settings property page to verify that the restore area is recognized and is ready for use. You will see the name of the restore area on the Post Office Settings page next to the field that reads Restore Area.

After the restore area is set up and configured, you will need to find the backup that holds what is believed to be the correct post office message store before the time the user was deleted. You'll then prepare to restore it using your backup application. It's important to make sure that, in your restore area, you have sufficient space to restore the post office from backup.

After a restore area is defined and the data is restored, there are two methods for restoring mail messages. The first method allows users belonging to the membership of a restore area to access their restored messages from within the GroupWise client. Users can then "cherry-pick" messages that they want to restore. The second method requires no effort on the part of your users. With this second method, the GroupWise POA restores all messages on behalf of the users.

It is important to note at this point that there is a slight difference between the users restoring their own mail and the administrator performing this operation through ConsoleOne. If the user has been deleted and then re-created, that user's mailbox is now empty. The user has no folder structure other than the default folders that any new account has. If the user is told to restore his mail, as is explained next, the mail that he chooses to restore will not preserve the folder structure from the backup location into the production system unless the user manually creates the folder structure in the production system first.

If the administrator kicks off the restore through ConsoleOne, and then the POA performs the entire restore operation, the POA will preserve the folder structure from the backup location into the production system. Therefore, if the user has been deleted and re-created, it's best to use ConsoleOne and let the POA restore the user's messages. On the other hand, if the user does not use many folders and does not mind if the restored messages end up in the Mailbox folder, either option works fine.

Before you actually restore the user's mail, you must verify that the production POA agent has Read, Write, Create, Erase, Modify, and File Scan rights to the restore area. If this is not set, you will see 8200 and possibly 8209 errors on the POA and on the client if the user is initiating the restore. The easiest way to verify this is to browse to the properties of the restore directory in ConsoleOne. Click the Trustees tab, and make the POA object a trustee of this directory.

Restoring MessagesUser and Windows ClientBased Message Restoration

Now that you've restored the message store to the restore area, you should notify users and, if necessary, assist them in recovering the deleted messages. At this point, you should have already assigned membership rights for the restore area to the users who will be accessing the restore area. You should also already have made the user's POA object a trustee of the restore area if the POA is running on the NetWare platform. If the POA is running on the Linux platform, just make sure that the mount point to the restore area is preestablished before the user attempts to restore mail items.

Tip

If your users have any auto-delete or auto-archive preferences set up on their live mailboxes, you should disable those temporarily. If you do not, restored items that pass the time threshold defined in the user's mailbox will be deleted or archived as soon as they are restored.

Follow these steps to open the backup area and recover the deleted messages:

1.
Start the GroupWise 7 client and select the File menu.

2.
Select the Open Backup command, as shown in Figure 28.3. The client will authenticate to the restore area if the user has rights to the restore area. With GroupWise 7, though, even if users do not have rights to the restore area, as long as the POA does, the POA will restore message items on behalf of the users.

Figure 28.3. Accessing the restore area in the GroupWise Windows client

[View full size image]

3.
Browse through the restorable messages and highlight the ones that need to be returned to the mailbox. You can select random messages with a Ctrl-click. You can select all messages by selecting the first message, moving down to the last one, and Shift-clicking the last message.

4.
After you've highlighted the messages, right-click one of them and choose the Restore command.

5.
After the messages are restored, close the restore area by selecting the File menu and selecting the Open Backup command. You will be returned to the main mailbox and should see the recovered messages.

6.
When restoring messages via the Windows client, you can also restore items that are in the trash of the Backup mailbox. To do this, though, you must undelete the items from the trash in the Backup mailbox, and then restore the items. These items will not automatically move to the trash; you must delete them yourself.

Note

When you're restoring mail through the client, the restored messages are placed in the mailbox folder unless the folder they are contained in also exists in the online mailbox. In other words, unless the online mailbox folder structure matches what is in the backup mailbox, mail that is restored will be placed in the mailbox folder.

This process of restoring messages works, but it isn't as slick as having the POA restore the user's messages, which is explained in the next section.

Restoring MessagesAdministrator and POA-Based Message Restoration

This method has one distinct advantage over having the user perform the restore: The POA-based message restore will create any folders that do not exist in the online mailbox but that do exist in the backup location, and place the mail in the appropriate folder. This preserves the user's folder structure.

Tip

If your users have any Auto-Delete or Auto-Archive preferences set up on their live mailbox, you should disable those temporarily. If you do not, restored items that pass the delete or archive time threshold defined in the user's mailbox will be deleted or archived as soon as they are restored.

At this point you should have already assigned membership rights to the restore area for the users (or post office) whose mailboxes are to be restored by the POA. This way when you issue a restore of a user's mailbox through ConsoleOne, the POA will correlate the user's membership to a restore area, and then know which UNC path to go to in order to access the backup of the post office. In a NetWare environment you must have also made the live POA object a trustee of the backup path with full rights. Follow these steps to task the POA with restoring a user's mailbox:

1.
In ConsoleOne, highlight the user whose message items you need restored.

2.
From the Tools menu, select GroupWise Utilities, Backup/Restore Mailbox. A dialog box similar to the one shown in Figure 28.4 should appear.

Figure 28.4. Issuing a mailbox restore from ConsoleOne

3.
Click the Yes button; this will send a message to the POA to restore the user's mailbox. Figure 28.5 shows the verbiage in the GroupWise POA's log when the user is restored. In this example, the logging level is set to verbose.

Figure 28.5. The GroupWise POA restoring a user's mailbox

[View full size image]

Now the user's account and mailbox are restored; they can begin functioning without any problems.

Note

This is when you might see an 8200 or 8209 error. The most common cause of these errors is that the POA is not a trustee of the restore area, or that the POA cannot access the restore area for some reason. we have seen a few occasions on which the POA was reporting an 8209 error when it did have the necessary rights to the restore area. If you see this, you might find that it is best to place the restore area on the same server on which the POA is running.


Import and Restore or Archive a User's Account

The Import and Restore or Archive method of bringing back a deleted user's account is the most complete method. Not all the needed utilities are built into the GroupWise 6.5 and 7 Backup/Restore Mailbox utility. The Import and Archive method brings back all the items that the Restore and Recover method does, in addition to the following items:

  • Personal address books

  • Trash items (if you want them)

  • Rules and proxy settings

The only attributes of the mailbox that this method does not restore are any preferences that the users set up in their mailboxes before their deletion.

Prerequisites

You must have the following three items before getting started:

  • The most recent backup of the entire CORPPO's post office directory structure, restored to a server somewhere in your network. If you don't have a backup, you can't go any further.

  • The GroupWise 6.0 ConsoleOne snap-ins that allow you to do an Import/Export from ConsoleOne. You can obtain the GroupWise 6.0 Import/Export Utility on Windows 95/98/NT/2000 from www.support.novell.com.

  • The FID that the user had before being deleted.

Bringing a GroupWise Post Office Back from Backup

You will need the entire post office directory structure and the contents of those directories to make this solution work. Sometimes, administrators think that just bringing the USER xxx.DB back from backup is enoughit's not!

When you bring the post office back from backup, you should place it in some location other than where the current live post office is located. It can be on the same server, just a different location. Before you attempt to bring the post office back from backup, make sure that you have sufficient space to do so.

Installing and Configuring the GroupWise 6.0 Import/Export Utility

GroupWise 7 does not ship with an Import/Export utility. The Import/Export utility you are instructed to use was made during the GroupWise 6.0 period, but it can be installed into ConsoleOne and used with a GroupWise 7 environment. When the Import/Export utility is incorporated into the GroupWise 7 ConsoleOne snap-ins, you can skip this entire section.

Following are the steps for importing a user into the GroupWise directory:

1.
Download the GroupWise 6.0 Import/Export utility on Windows 95/98/NT/2000 from the Novell website; the best way to find this tool is to go to the Knowledgebase and search for GWPORT32.EXE.

2.
Place the downloaded file GWPORT32.EXE in the CONSOLEONE\XX directory, for example, C:\NOVELL\CONSOLEONE\1.2.

3.
Exit ConsoleOne.

4.
Run the GWPORT32.EXE utility from the C:\NOVELL\CONSOLEONE\1.2 directory. You should see a dialog box similar to the one shown in Figure 28.6.

Figure 28.6. Extracting the GWPORT32.EXE utility

5.
Start ConsoleOne, select an Organization Unit (OU) in the eDirectory view, and then select Tools, GroupWise Utilities. You should see the Import and Export menu commands, as shown in Figure 28.7.

Figure 28.7. The GroupWise Import and Export utilities in ConsoleOne

[View full size image]

If you receive errors when trying to run the Import utility, delete the following Registry keys in your Windows Registry, because this section can conflict sometimes with the Import/Export utility you just installed:

HKEY_CURRENT_USER\Software\NetWare\Parameters\NetWare Administrator

and

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\LIBRARY

Strategies for Determining a User's FID

To bring the user back, through an import that you will do soon in this chapter, you must know the user's three-character FID. Here are some ideas for determining the FID:

  • Ask the user; there's a possibility the user might know.

  • Consider whether the user had an archive directory. If, for example, the user's archive directory is C:\ARCHIVE, there will be a folder under C:\ARCHIVE with a name of OF XXX ARC. The XXX is the user's FID.


Bringing the User Back

When bringing a user back from deletion, you must restore the user's GroupWise directory object.

It's possible that you have already re-created the user so that the user has an account in the meantime. That's a common thing to do. However, at this point, you cannot have a second account for the user before proceeding. The person can have an eDirectory/NDS account, though. If the user has items in the new mailbox, get rid of the mailbox. You can have the user forward the message items to you or someone else for safekeeping.

Importing the User's Object

The process of importing a user is very precise. Follow these steps closely for a successful import of the user:

1.
Determine the following information about the user to be imported:

  • The user's last name.

  • The user's eDirectory common name. This is often referred to as the user's short name. For example, if my eDirectory name is TKRATZER.NY.WWW, my common name is TKRATZER.

  • The user's GroupWise FID.

  • The mailbox ID for the user if his mailbox's ID does not match his eDirectory common name. The mailbox ID will not be used in the import file; it will be used if the mailbox ID and the eDirectory common name are different. You can make the change to the mailbox ID after importing the user.

2.
Create a user import file in an ASCII/text editor. Figure 28.8 shows an example of such a file in Notepad.

Figure 28.8. A user import file in Notepad

[View full size image]

Do not add any extra keystrokes; the import file follows a very strict format. The user in this example has a last name of Kratzer, an eDirectory common name of TKRATZER, and a FID of 5nw, followed by one carriage return (press Enter once).

3.
Save the file as C:\USER.TXT.

4.
Launch ConsoleOne.

5.
Connect to the domain that owns the post office you are going to import TKRATZER to.

6.
Launch the Import/Export utility. To do this, go to the eDirectory Browser view, highlight an eDirectory OU (any OU is fine), and select Tools, GroupWise Utilities, Import.

Note

It might take a long time for this utility to launch; just be patient.

7.
Inside the Import/GWPORT utility, do the following, as shown in Figure 28.9:

  • Set NDS/GroupWise Class to User.

  • From the Parent: GroupWise Post Office list, select the post office this person will be associated with.

  • Set Import File to C:\USER.TXT.

  • Make the following selections under Attributes (when you double-click these attributes, they will be placed in the File Fields section): Last Name, (Object Name), NGW: File ID.

  • Under Starting Destination Context, select the context the user will be imported into. This user might already exist in eDirectory, but this does not matter.

  • Do not make any other selections.

Figure 28.9. Configure the GroupWise Import Utility to bring in these three file fields

[View full size image]

8.
Click the Run button; this will import the user. When you click Run, you get an Import dialog box. It might just stare at you for a while, but eventually it will come back. You might have to flip screens with the Alt+Tab keystroke sequence to get the GroupWise Import dialog box shown in Figure 28.10. The goal is for the Import utility to indicate that one user object was imported, as shown in Figure 28.10.

Figure 28.10. The GroupWise Import dialog box is showing a successful import

9.
Click OK to get out of the Import utility. From ConsoleOne, finish the rest of this process.

10.
Edit the user's object in the eDirectory browser view, and enter the given name.

11.
Enter any other information about the user that you need to. Then exit out of the user's settings by clicking OK. You should now be able to see TKRATZER from the GroupWise view.

12.
Confirm that TKRATZER actually has the FID you specified. (We've seen situations in which the FID was QXX. If you get this condition, make sure you are connected to the user's owning domain; then delete the user and try again.)

It's easy to see when your import is successful. Importing can be difficult for some customers. The important thing to remember is the syntax in the import file. Make sure that it is perfect, including just one carriage return at the end of the import file.

Obtaining Access to the User's Message Store on the Backup Post Office

You have imported the user's object with the correct FID, so now you need to configure the post office so that you can access the message store at the post office you brought back from backup. Every GroupWise post office has two security locks, so to speak. Those security locks are the WPHOST.DB file and the password on the user's USER xxx.DB file. To access the post office and the user's mailbox you restored from backup, you need to reconfigure the security locks to your advantage. On the post office database/WPHOST.DB file, you must do the following:

  • Change the security level to low.

  • Configure the post office to support direct connections. On the USER xxx.DB file, you must change the password to one that you know, in order to have access to the mailbox.

Here are the step-by-step instructions for accessing a user's message store (mailbox). You do not want to affect your live system with the changes you are going to make, so first you will have to spoof your system a bit:

1.
From the domain directory, copy the WPDOMAIN.DB file for the domain that TKRATZER is now a member of from your live system to the C:\GWDOM directory. Also copy the GWPO.DC file from that same location to the C:\GWDOM directory.

2.
In ConsoleOne, make sure that the GroupWise snap-ins are connected to the WPDOMAIN.DB at the C:GWDOM directory. You can do this by selecting Tools, GroupWise System Operations. Select Domain. Specify the path as C:\GWDOM.

3.
Edit Tay Kratzer's object, and on the GroupWise Account page, change Tay's GroupWise password to 123.

4.
Edit the properties of the post office that Tay Kratzer is a member of (not the POA, the post office object):

  1. Go to the Post Office Settings page under the GroupWise tab and change the Access Mode to Direct Only.

  2. Now access the Security page on the GroupWise tab of the post office object. Change the security level to Low.

All the changes you made should not affect the live system because you are connected to WPDOMAIN.DB on the local hard drive.

Now you need to build the WPHOST.DB file for the post office that TKRATZER is a member of. You will place this WPHOST.DB file in the post office directory that you brought from backup. To do so, follow these steps:

1. | Highlight the post office object in the GroupWise view, and then select Tools, GroupWise Utilities, System Maintenance.
2. | Select Rebuild Database and then click the Run button.
3. | When prompted for a path, specify the location of your backup post office directory, and click OK.

For this procedure you have been temporarily connected to the WPDOMAIN.DB file in the C:\GWDOM directory. It's important to make sure that you disconnect ConsoleOne from this WPDOMAIN.DB and connect to a WPDOMAIN.DB on your live system, which is on a server location. We suggest doing this right now. If you do not do this, the next time you load ConsoleOne it will remember that you were connected to the domain on the C: drive, and will attempt to connect here. You might not notice that you are not connected to a production database, and all your administration changes will be for naught.

Now with the newly configured WPHOST.DB in place at the post office you brought from backup, you are just about ready to get in. You need to push Tay Kratzer's mailbox password of 123 down to the USER xxx.DB. Here's how to this:

1.
Run the standalone GroupWise GWCheck.

2.
Fill in the correct information to reset Tay Kratzer's password. Figure 28.11 shows you what settings to select.

Figure 28.11. The GWCheck job used to reset a password

[View full size image]

Now the user's message store is ready for you to access it. Here's what you do. Use the following command line to access the post office in direct mode:

GRPWISE.EXE /@U-USERID /PH-PATH TO POST OFFICE

For example:

GRPWISE.EXE /@U-TKRATZER /PH-F:\GWAVARE

Exporting a User's Mailbox

Those of you familiar with the Archive feature might wonder why we refer to these next steps as exporting. It's because there's more to the procedure than just using the Archive feature. A user's mailbox doesn't contain only messages; it comprises the folder structure the user has created, as well as the user's address books, calendar items, and even trash items. Perhaps this is too sentimental a notion for you, but many users see their email as an office of sorts. People are rather sensitive about their mailbox. You won't always be able to restore shared address books, shared folders, rules, and personal preferences, but if you are restoring the mailbox for an accidentally deleted user, you should take care to restore everything you possibly can.

Configuring the Archive Directory

First, you need to specify an archive location in order to create an Archive mailbox. Before doing this, though, you need to take some precautions. We have had experience in the past with Windows caching data rather then writing it to the hard drive. When you are archiving so much data, it might be better to specify the archive path to a NetWare server. The NetWare client does a much better job than Windows does of handling data. It decreases the likelihood of corruption to the Archive mailbox when you're archiving a large bunch of data at one time.

Here are the steps for specifying the archive directory:

1. | From inside the user's mailbox, select Tools, Options, Environment, File Location, Archive directory.
2. | Specify an archive directory.
Configuring the Mailbox Folder Structure for Export

Many users have created an elaborate folder structure under their mailbox and cabinet. When you archive messages, the folders that have messages in them are automatically created in the Archive mailbox. When you eventually unarchive these items, the folder names are created again in the live mailbox. However, folders containing nothing at the time you performed the archive will be lost. Again, the idea is to try to duplicate the mailbox as closely as possible. Following are the steps for exporting the folder structure from a mailbox to the Archive mailbox:

1.
Find one small message item in the user's mailbox. You'll use it to export the folders in this mailbox.

2.
Highlight the item and select Edit, Move/Link to Folders.

3.
In the resulting Move/Link Selections to Folder dialog box, check each folder within the Cabinet object. If the user has other folders under the mailbox that are not in the cabinet, you can place check marks next to those. Figure 28.12 shows an example of this step.

Figure 28.12. Linking a message item to all folders

[View full size image]

4.
With the check marks in place, click the Move button. This action creates a virtual copy of this message in every folder in the mailbox. Get out of the Move/Link option. When you archive, each of the folders will be created because there is an item in each of the folders.

Check in some of the folders and make sure that all of them have a copy of the message you linked to the folders.

Exporting All Message ItemsEven Sent Items and Personal/Posted Items

It is time to export the real meat of the mailbox. The easiest way to determine whether you archive everything in the mailbox is to use the Find feature in the GroupWise mailbox. Select Tools, Find; make no additional selections from the Find dialog box; and then click OK. This way, you are telling GroupWise to find everything. If this user is tidy or if you have an aggressive email retention policy, perhaps you'll just find a few hundred items. However, many times you will find that there are thousands of items, maybe more.

The problem with this is that the Find window will not display that many items. So you might need to alter your Find query to find only items in a certain period or of a certain type. When you choose Tools, Find, you can alter the scope of the query by using the Date Range section. You can also modify the results from the Find window by selecting Tools, Modify Find. We'll leave that to you. The idea is to get a maximum of about 4,500 items in the Find window, and then modify the Find window to get the next batch of items.

Your goal is to eventually find, and then archive, all the message items in the user's mailbox. Here's an example of the steps for doing this; you might need to deviate from these steps to pare down the results:

1. | Inside the user's mailbox, select Tools, Find. Make sure that the Find tab is active, and not the Find by Example tab.
2. | Do not check or uncheck anything. Take the defaults by clicking the OK button. If you suspect that this user has more than 4,500 items throughout her mailbox, modify the find by using the Date Range feature.
3. | This process will find all message items. Select the first 500 or so items by Shift-clicking them. Then select Actions, Move to Archive.
4. | Repeat step 3 (and possibly step 2) until all items have been moved to the Archive mailbox.

This process of archiving the items from the Find query should find calendar items, be they group or personal calendar items, and all message items if they are sent or received. Ideally, this process will move all message items from the master mailbox to the Archive mailbox. When the process finishes, the mailbox should look like a ghost town, perhaps with a bunch of empty folders.

Tip

This process of using the Find feature and archiving messages archives all the user's Sent Items. Beginning with GroupWise 7, the Sent Items folder is no longer a find results folder. As a result, it is now created by default in the archive. So the user will see her sent items in the Sent Items folder by default. In earlier versions of the GroupWise client, this was not quite the case, and you had to create the Sent Items folder manually in the archive.

Tip

We've been using third-party tools from many vendors, and one of them, Advansys, has created a development framework called Formativ. In this development framework you can easily create some very interesting tools, and one of the tools we've made together with Advansys is an "Archive/Unarchive all" applet. This applet has been used to archive thousands of mailboxes, including an export of the user's address books, and unarchive them elsewhere. Although it's not a publicly available tool, you can check out Formativ at www.advansyscorp.com and send an email to inquire about this tool.

Exporting the TrashIt's Quick!

If you bring back the user's trash, the user is going to think you performed wonders, and it takes just a minute. The steps to perform this task are as listed here:

1. | Create a new folder in the cabinet of the user's mailbox (not the Archive mailbox) called TRash2.
2. | Go to the trash and Shift-click to select all items. Drag them to the new trash2 folder you created.
3. | Go to the TRash2 folder you created under the cabinet, Shift-click to select all items, and then select Actions, Archive.

Note

The section "Importing Mail/Folders and Trash Items," a little later in the chapter, describes how to move these trash items in the trash2 folder back to the trash bucket in the user's live mailbox.

Exporting the Address Book

Every user has at least two address books and quite often more than that. These two address books are the Frequent Contacts address book and the address book containing the user's full name. The user you are working with might even have more. You can export the user's address books, and then import them (later) into the user's address book in the live mailbox. The following steps illustrate how to do this:

1.
Go to the GroupWise Address book by selecting Tools, Address Book.

2.
Choose an address book to export by clicking the address book in the left panel (not the Novell GroupWise Address Book; that's your system address book, not a personal address book).

3.
Inside the address book, select File, Export, Entire Address Book. Figure 28.13 shows this dialog box.

Figure 28.13. Exporting the GroupWise address book

[View full size image]

4.
Save the file as an *.NAB file. You might want to name the *.NAB files according to the name of the address book, for example, TKRATZER-Frequent Contacts.NAB.

Now you've exported everything you possibly can. You might want to check the user's rules and proxy settings and make a note of them. You will have to manually re-create them in the live system.

Next, you need to access the user's live mailbox and start the import operations.

Importing a User's Mailbox

You need to access the user's live mailbox, so you might need to reset TKRATZER's password in order to get in.

When you get into TKRATZER's live master mailbox, the process you follow is nearly the opposite of the Export process. First, though, for the Find feature to work on the Archive mailbox, you must access the Archive mailbox and then exit GroupWise. GroupWise needs to rebuild the QuickFinder index on the Archive mailbox. Exiting GroupWise after GroupWise has discovered that it has new indexing to do causes the QuickFinder index for the Archive mailbox to be rebuilt.

Importing Mail/Folders and Trash Items

To import mail, folders, and trash items, get into Tay Kratzer's live GroupWise mailbox, not the one on the backed-up post office, and perform the following steps:

1. | Go into Tools, Options, Environment, File Location, Archive directory. Specify the archive directory that you specified earlier in this chapter. If prompted to move the archive, be sure to answer no.
2. | Go into the Archive mailbox by selecting File, Open Archive. Exit GroupWise (on older GroupWise clients, this allows GroupWise to reindex the Archive mailbox). The index is essential when you're using the Find feature mentioned in the next step.
3. | Get back into GroupWise and select File, Open Archive. From within the Archive mailbox, select Tools, Find. Find the items in the same manner in which you did when you archived messages into the Archive mailbox. Be sure to select the Find tab, and not the Find by Example tab. (If the Find feature does not find any items, try exiting GroupWise again.)
4. | Select the items in the Find Results view and select Actions, Move to Archive (this actually unarchives the items and moves them back to the Master mailbox). Repeat this step until all items are unarchived.
5. | Now enter the master mailbox (rather than the Archive mailbox). You should see your message items, and all the folders that were created. You still need to deal with the trash.
6. | Make sure that you're in the master mailbox, not the Archive mailbox. Delete the TRash2 folder under the Cabinet, as well as all the messages in this trash2 folder. This will move them to the trash bucket on the Master mailbox. Now the user's message data is imported, and it should be available for you to view in the master mailbox.

Now all message items are in place, and the user's mailbox should look very much the same as it did before someone slipped on the banana peel that caused them to hit the Delete button and the OK button in succession.

Importing the Address Books

Importing is the opposite of the exporting you performed. Inside the GroupWise Address book, you should see at least two personal address books. They are the Frequent Contacts address book and the address book with the user's name. If they are there, follow these steps:

1. | Highlight one of the address book tabs for an address book you will import, and select File, Import.
2. | Specify the correct *.NAB file for this address book. This should be the *.NAB file you exported earlier.
3. | If the user had more address books than the two default address books, you will have to create the address book tabs for these address books before attempting to import the *.NAB file. To do this, simply select File, New Book and create the address book with the same name as before.

Now you have imported all the data you can restore.

Final Notes About the Import Process

The import process does not import the following less common attributes about a mailbox:

  • Rules

  • User preferences

  • Saved Find folders

  • Button bar and toolbar settings

  • Home page settings

You can go back into the backup mailbox and gather this data. You can try to re-create it in the live mailbox.

Additionally, earlier in the document you might have linked a message item to several folders, in order to re-create the folder structure. You don't want that item linked to all the folders, so take these steps:

1. | Find one instance of that message item that is linked to all the folders.
2. | Forward the message as an attachment from Tay Kratzer to Tay Kratzer. This way, the message isn't lost.
3. | Archive the one item, and it will no longer be in all the folders. You can delete the archive; it's no longer needed.

After you've taken all of these steps, the mailbox should look and behave in much the same way as it did before.


Summary

This chapter discussed two methods for recovering a deleted user's GroupWise account. It also covered two methods for recovering a deleted user's mailbox message items. GroupWise 7 makes it much simpler to re-create a deleted user and restore the user's settings. You can now perform all of these functions through ConsoleOne, and you don't even have to bother your users. The user's mail just appears as if by magic. Life is good.


Chapter 29. Configuring a GroupWise Messenger (Instant Messaging) System

This chapter discusses installing a basic GroupWise Messenger system. However, we recommend that for more troubleshooting ideas and general documentation you refer to the online documentation for GroupWise Messenger 2.0 located at http://www.novell.com/documentation or the documentation that comes with your version of GroupWise Messenger.


Architectural Basics

GroupWise Messenger is an instant messaging collaboration tool. A GroupWise Messenger system can run independent of your GroupWise system, and it has no dependencies on GroupWise. As of the writing of this book, the only level of integration between GroupWise Messenger 2.0 and GroupWise 7 is integration at the client level. Also, GroupWise Monitor can monitor the GroupWise Messenger Agents. The GroupWise Messenger Windows client can launch a new GroupWise message to compose, and the GroupWise 7 Windows client can launch a GroupWise Messenger session. The GroupWise 7 Windows client can also dynamically show in the GroupWise client whether a GroupWise Messenger user is actually available in his GroupWise Messenger client. Although this integration exists, neither client has a dependency on the other.

Client Software

The GroupWise Messenger client currently runs on the Windows desktop platform, and a GroupWise Messenger client exists for Linux and Macintosh.

The GroupWise Messenger client is currently not compatible with other instant messaging solutions, such as those provided by AOL, MSN, and Yahoo.

Server Software

The server software is actually called "Novell Messenger" in the server interface for this software. As you install and work with your messenger system, you will see the Novell Messenger theme used often in the naming structure of files and directories. There are two server components for Novell Messenger: the Messaging Agent and the Archive Agent. The Messaging Agent relays IM (Instant Messenger) conversations between GroupWise Messenger clients. The Archive Agent, which you are not required to run, allows those conversations to be archived. Some customers will want to use the Archive Agent, particularly when GroupWise Messenger is used for its conferencing capabilities.

The GroupWise Messaging and Archive Agents run on the NetWare, Linux, and Windows Server platforms.

Administration Software

GroupWise Messenger is configured through GroupWise Messenger snap-ins to ConsoleOne version 1.3.6 or higher. The GroupWise Messenger administration database is eDirectory. The GroupWise Messenger system in no way uses the GroupWise Directory Store (the WPDOMAIN.DB and WPHOST.DB files).

Directory Software

The GroupWise Messenger directory is Novell eDirectory. GroupWise Messenger clients authenticate to eDirectory, and eDirectory is their directory for populating their GroupWise Messenger buddy list. eDirectory is also used to hold some user preferences. For example, a user's buddy list is held in eDirectory. Because of this, keep in mind the health of your eDirectory tree.

GroupWise Messenger users do not need to have the Novell client in order to use GroupWise Messenger, although they do need a full eDirectory account. We like to call this a "red-shirt" account. If your have users who are GroupWise external entities (the ones with green shirts), they will not be able to participate as GroupWise Messenger users. You must convert them to full eDirectory accounts in order for them to use GroupWise Messenger. Chapter 7, "GroupWise Utilities and Diagnostics," talks about how you can convert a GroupWise external entity into a full eDirectory user.

Configuration Files

The GroupWise Messenger agents have configuration files. However, many of the switches available in these configuration files can be modified through the ConsoleOne snap-ins. The most important switch for a GroupWise Messaging or Archive Agent is the one that tells it where in eDirectory its object exists. This is similar in function to the /Home switch on the GroupWise agents, but rather than pointing to a domain or post office database, it points to the eDirectory object that holds the configuration information for the agent.


Creating a Basic GroupWise Messenger System

GroupWise Messenger is simple to install. This section states some obvious points and indicates some potential trouble areas.

Preparation

There is no GroupWise Messenger administration view, as there is for GroupWise. I therefore recommend that you create a new eDirectory OU to house the components of your GroupWise Messenger system that you will be administering. You might call this OU IM or GWIM. Where you put the OU is not all that important from an eDirectory tree walking perspective. When your users populate their buddy lists, they will be adding data to the partitions they happen to be in. Your users do not need any additional eDirectory rights to use GroupWise Messenger. The GroupWise Messenger logs in as sort of a "superuser" on behalf of all users. From an administration standpoint, you can control who users can see. So in effect you can make some users invisible to the GroupWise Messenger system.

Your eDirectory tree must be configured to support LDAP. The GroupWise Messaging Agent can run without LDAP support; however, I do not recommend it. We have found that not using LDAP causes the Messaging Agent to have difficulties authenticating users or searching eDirectory. LDAP is a lot faster and more efficient.

Your eDirectory tree must be healthy. If it's not, GroupWise Messenger will expose that fact. We recommend that you perform a basic eDirectory health check. We also recommend that you regularly check the health of your eDirectory according to Novell's recommendations. A good place to start this process is at Novell's documentation site, www.novell.com/documentation.

The GroupWise Messenger server software does not have a lot of overhead. Of course, it's all relative to the number of users you will have using GroupWise Messenger. Many organizations place their GroupWise Messenger Agents on a server that is dedicated for this purpose only.

The server that will run your GroupWise Messenger agents should have a DNS address, for example, IM.WWWIDGETS.COM. You might also want to consider making this server accessible through the firewall to service users on the road.

Server and Administration Installation

This section walks you through a basic GroupWise Messenger system installation. This scenario installs GroupWise Messenger to a NetWare server:

  1. Browse to the GroupWise Messenger installation CD or directory. Run setup.exe.

  2. Select the Install Server menu choice.

  3. Proceed to the Installation Options screen and choose Create or Update a System.

  4. At the Server Information screen, choose a path to a NetWare server. This should be the path to a NetWare server that will be running your GroupWise Messenger Agents. A GroupWise Messenger Software Distribution Directory will also be created at this location. Click Next.

  5. At the System Configuration screen, I recommend that you keep all defaults and specify an eDirectory OU that you have created specifically to contain your GroupWise Messenger administration components. Click Next.

  6. Allow the installation to extend the eDirectory schema of your tree, if needed.

  7. From the Install Components screen, be sure to install the GroupWise Messaging Agent and the administration files. The Archive Agent is optional, although this example installs it. Click Next.

  8. From the Directory Access Configuration screen, shown in Figure 29.1, indicate the IP address to your LDAP server. In a pure NetWare environment, this is the server that's running NLAP.NLM. Keep the standard LDAP port of 389, unless your LDAP server happens to be configured to use a different port. It's important to fill in the Root Certificate field. LDAP requests are typically sent over the wire using clear text. However, the GroupWise Messenger will support SSL encryption of the LDAP request if your GroupWise Messaging Agent has the root certificate from the Novell server that is running NLDAP.NLM. In the UNC path, therefore, enter the path to the ROOTCERT.DER file on the server running your NLDAP.NLM. Click Next.

    Figure 29.1. The Directory Access Configuration screen is used to specify which server is running LDAP in your eDirectory tree

    [View full size image]

  9. From the Directory Authentication screen, enter the authentication information for the superuser. This user must have administrative-level rights. Figure 29.2 shows a superuser called GWIMSUPERUSER for this example. Click Next.

    Figure 29.2. The Directory Authentication screen

    [View full size image]

  10. At the User Configuration screen, the best location for most customers is the organizational-level sections at the top of the tree. You might also want to choose the Include Sub Contexts option. This will allow users in any part of the tree to authenticate to your GroupWise Messenger Agent, and it will also let users search for their buddies no matter where they are in your eDirectory tree. Click Next.

  11. At the Server Address screen, you should most likely keep the defaults. If possible, you should use a DNS address rather than an IP address. DNS addresses are easier for users to remember. When you install the GroupWise Messenger client onto users' desktops, there is a way to configure the GroupWise Messenger client to know what the address of the GroupWise Messaging Agent is so that you do not have to educate your users about this address. Click Next.

  12. The Security Configuration screen allows you to enable SSL. You definitely want to do this. However, you can enable this later if you want. Chapter 27, "Securing Your GroupWise System via SSL," talks about how to enable SSL with GroupWise Messenger. Click Next.

  13. At the Admin Configuration screen, indicate the path to ConsoleOne so that the installation can install the GroupWise Messenger snap-ins to ConsoleOne. Click Next.

  14. Review the installation summary, and then click Next to allow the software to install.

You have now created a basic GroupWise Messenger system. It can function right away.


Starting Your GroupWise Messenger Agents

The command to start your GroupWise Messenger Agents is NMSTART.NCF. This NCF file is located in the NOVELL\NM directory, wherever you installed the GroupWise Messenger software tofor example, SYS:NOVELL\NM. Here's an example of an NMSTART.NCF file:

load sys:\Novell\NM\ma\nmma.nlm @sys:\Novell\NM\ma\strtup.ma
load sys:\Novell\NM\aa\nmaa.nlm @sys:\Novell\NM\aa\strtup.aa

When I installed my GroupWise Messenger system just now for this chapter, and then tried to load the GroupWise Messenger Agents using the NMSTART.NCF file, the agents would not load. I got this error:

Agent configuration failure [0xAD2D]
Cause: LDAP Server is not available

Here's what I did to successfully resolve this error:

  1. Edit the STRTUP.MA file, which will typically be in the SYS:\NOVELL\NM\MA directory.

  2. Find the following two switches, and place a semicolon before them to disable these switches:

    ;/ldapipaddr-137.65.55.211
;/ldapport-389

  3. Go into ConsoleOne. Find the MessengerService object and expand it, as shown in Figure 29.3.

    Figure 29.3. The MessengerService object in eDirectory

    [View full size image]

  4. Highlight the LDAPContainer object. Right-click and select New, Object, nnmLDAPProfile.

  5. Give a name to the new LDAP Profile. Select the Define Additional Properties check box.

  6. On the General property page of the LDAP profile that you just created, fill in the following fields:

    Base DN: This will often be the root organization of your eDirectory tree.

    Username: In this scenario, the name of the user is CN=GWIMSUPERUSER,O=AMERICAS.

    Here's another example: CN=GWIMSUPERUSER,OU=NY,OU=WWW,O=AMERICAS.

    Notice that there are commas that delimit the portions of the user's fully distinguished eDirectory name. LDAP uses commas, not periods, to delimit a user's full directory name.

    Click the Set Password button and fill in the password for the user you just configured in the Username field.

    Figure 29.4 shows the configuration of the sample scenario.

    Figure 29.4. The LDAP Profile general screen

    [View full size image]

  7. Now go to the Connections property page under the LDAP Profile tab.

  8. Click the Add button. Fill in the address to your LDAP server; specify the LDAP port number of 389 instead of 636, which is the SSL port; and set the preference for the LDAP server at 0. (Enabling SSL is covered in Chapter 27.) Figure 29.5 shows a configured LDAP server connection.

    Figure 29.5. A configured LDAP server connection

    [View full size image]

  9. Click OK to save your settings. Now, when you run the NMSTART.NCF file, the GroupWise Messaging Agents should start. Figure 29.6 shows the GroupWise Messaging Agent console screen on a NetWare server.

    Figure 29.6. The GroupWise Messaging Agent console screen

    [View full size image]

You have now defined an LDAP server for the GroupWise Messenger system to use. The LDAP services are necessary for users to authenticate, as well as add other users to their buddy lists.


Installing the GroupWise Messenger Client

The GroupWise Messenger client installation is actually very flexible. There are various ways you can install the client:

  • Install the GroupWise Messenger from the GroupWise Messenger Software Distribution Directory.

  • Enable client installation from a Web browser to the GroupWise Messenger Agent.

  • Install the GroupWise Messenger client along with the GroupWise Windows client installation.

This chapter covers all three of these GroupWise Messenger client installation methods.

But first, before we cover these methods in more detail, there are some concepts regarding GroupWise Messenger client installation files you should have a handle on.

Understanding the GroupWise Messenger Client Installation Files

The GroupWise Messenger installation created a Software Distribution Directory. Remember the NOVELL\NM directory? The GroupWise Messenger client installation SETUP.EXE utility can be found in the \Novell\NM\ma\software\client\win32 directory. And much like the GroupWise Windows client installation software, it contains a SETUP.CFG file. It is important that you configure the SETUP.CFG file, no matter which method you use to install the GroupWise Messenger client. The best kind of installation is one that does not require the users to answer any questions. In the chapter example, we will configure the SETUP.CFG file without having to ask the users any questions.

Following are the steps for configuring the GroupWise Messenger's SETUP.CFG installation settings file:

1.
Edit the SETUP.CFG file, which is located in the \Novell\NM\ma\software\client\win32 directory.

2.
Configure this file as shown (specifying the language you desire):

[NMSetup]
Path=
ProgramFolder=
LaunchNow=No
LaunchOnStartup=No
ViewReadme=No
IconOnDesktop=Yes
RegKeyForDefaultPath=
RegKeyForDefaultFolder=
Software\Novell\GroupWise\Client\5.0\Folder
ServerAddress=im.wwwidgets.com
ServerPort=8300
ForceAddressAndPort=No
UseWindowsColors=

[Languages]
ChineseSimplified=No
Chinese=No
Czech=No
BrazilianPortugese=No
Danish=No
Dutch=No
English=Yes
Finnish=No
French=No
German=No
Hungarian=No
Italian=No
Japanese=No
Korean=No
Norwegian=No
Polish=No
Russian=No
Spanish=No
Swedish=No
Thai=No
Turkish=No

[ShowDialogs]
HideAllDialogs=Yes
SelectDestination=No
SelectProgramFolder=No
LanguageSelect=No
SetupComplete=No

3.
Save the file. If a NVLMSGR.EXE file exists in the same directory as the SETUP.CFG that you just modified, delete the NVLMSGR.EXE file, because it needs to be regenerated to incorporate the changes you just made.

4.
Bring the GroupWise Messenger Agent down, and then back up. When you do so, the GroupWise Messenger Agent will regenerate the NVLMSGR.EXE file.

5.
Now when your GroupWise Messenger installs, users will not be prompted with any installation questions. (Actually, if a user has already installed the GroupWise Messenger client, the user will be prompted as to whether she wants to uninstall the GroupWise Messenger client.)

The SETUP.CFG file is now configured so that users are not prompted with any installation questions when they install the GroupWise Messenger client.

Installing the GroupWise Messenger Client from the GroupWise Messenger Software Distribution Directory

This is a simple, yet manual, process necessary for your users to install the GroupWise Messenger client. You might consider launching the GroupWise Messenger installation from a login script if your users use the Novell client. Otherwise, follow these steps:

1. | Make sure that the SETUP.CFG file is configured how you would like it to be, as explained in the preceding section.
2. | Locate the \Novell\NM\ma\software\client\win32 directory.
3. | Run SETUP.EXE. The GroupWise Messenger client software will be installed.

The GroupWise Messenger client should install, without asking any installation questions.

Enabling Client Installation from a Web Browser to the GroupWise Messenger Agent

This is a slick way for your users to install the GroupWise Messenger client. Your users go to a location via their Web browsers and can install the GroupWise Messenger client from there. You don't even have to set up a Web server to do this; you simply have to enable this feature on your GroupWise Messenger Agent along with a few other steps.

Configure the GroupWise Messenger Client Extractor File

This is an interesting concept. The GroupWise Messenger client is actually compressed into an extractor file called NVLMSGR.EXE. This file is located in the \Novell\NM\ma\software\client\win32 directory. This file is a self-extracting zip file of the GroupWise Messenger client, including the SETUP.CFG and the SETUP.INI files.

The NVLMSGR.EXE file does not ship from Novell. It is actually generated the first time your GroupWise Messaging Agent loads. In fact, each time your GroupWise Messaging Agent loads, it checks to see that the client extractor NVLMSGR.EXE file is already created. The log will read as follows:

Client extractor already exists . . .
Client extractor successfully built . . .

Now, imagine that you tweaked your SETUP.CFG file. However, that change is not incorporated into the NVLMSGR.EXE file. To fix this, delete the NVLMSGR.EXE file, and then bring the GroupWise Messaging Agent down and back up.GroupWise Messaging Agent will re-create the file, and of course incorporate your newly created SETUP.CFG file. Here are step-by-step instructions for doing this:

1. | Make sure that the SETUP.CFG file is configured how you would like it to be, as explained earlier in this chapter.
2. | Locate the file NVLMSGR.EXE, which is in the \Novell\NM\ma\software\client\win32 directory.
3. | Delete the NVLMSGR.EXE file.
4. | Go to the GroupWise Messaging Agent console screen and unload the Messaging Agent by pressing F7.
5. | Reload the GroupWise Messaging Agent. The command to do this is typically NMSTART.

The GroupWise Messaging Agent will generate a newly configured NVLMSGR.EXE file. You should see the Messaging Agent report that it built the client extractor.

The GroupWise Messenger client extractor can now be used in a couple of ways. The next two sections talk about how to use the NVLMSGR.EXE file.

Install the GroupWise Messenger Client Through a Web Browser

This section walks you through the steps involved with installing the GroupWise Messenger client through a Web browser. Follow these steps:

1.
In a Web browser, enter the IP address or DNS name of the GroupWise Messaging agent, followed by 8300for example, http://im.worldwidewidgets.com:8300.

Note

This can be a complex address for your users to enter. You might just want to send it to them in an email message, which allows the users to then click the link.

Your users should see a screen similar to the one shown in Figure 29.7.

Figure 29.7. The GroupWise Messaging client Web browser installation screen

[View full size image]

2.
Click the Novell Messenger link and download the software.

3.
Run the NVLMSGR.EXE file. The GroupWise Messenger software will install.

This method is slick in some ways, but it still has some manual elements to it. Users must download the *.EXE file and then run it. I like the next method the best, because users aren't required to do much of anything.

Installing the GroupWise Messenger Client Along with the GroupWise Windows Client Installation

This method requires no intervention on the part of your users. This method requires you to read Chapter 12, "Administering the GroupWise Client," and understand it. Chapter 12 deals with how to install the GroupWise client. This section dovetails into the solutions already explained in Chapter 12.

Installing the GroupWise Messenger Client Along with a GroupWise Windows Client Mapped Drive Installation

As a prerequisite to this section, be sure to read the section in this chapter titled "Configure the GroupWise Messenger Client Extractor File," which explains how to configure a GroupWise Messenger client extractor file.

This method assumes that you already have a GroupWise Software Distribution Directory with a CLIENT directory that is already configured for installing the GroupWise Windows client. After having done so, follow these steps:

1. | Under the CLIENT\WIN32 directory there should be an ADDONS directory. If there is not one, create it.
2. | Create a directory under the CLIENT\WIN32\ADDONS directory called GWMSGR.
3. | Copy the configured GroupWise Messenger client extractor file called NVLMSGR.EXE from the \Novell\NM\ma\software\client\win32 directory to the SDD\CLIENT\WIN32\ADDONS\GWMSGR directory. Rename the NVLMSGR.EXE file in the SDD\CLIENT\WIN32\ADDONS\GWMSGR directory to SETUP.EXE.
4. | In the \Novell\NM\ma\software\client\win32 directory, there is a file called ADDON.CFG. Copy this file to the SDD\CLIENT\WIN32\ADDONS\GWMSGR directory.

Figure 29.8 shows a GroupWise SDD configured to also support the GroupWise Messenger client installation.

Figure 29.8. A GroupWise SDD with GroupWise Messenger installation support

[View full size image]

When users run the SETUP.EXE file from the SDD\CLIENT\WIN32 directory, it will install the GroupWise Windows client, and it will automatically run the GroupWise Messenger installation.

Installing the GroupWise Messenger Client Along with a GroupWise Windows SETUPIP Installation

As a prerequisite to this section, be sure to read the section in this chapter titled "Configure the GroupWise Messenger Client Extractor File," which explains how to configure a GroupWise Messenger client extractor file. This method assumes that you already have configured your Web server with a GW7CL directory (explained in Chapter 12). Follow these steps:

1. | Under the GW7CL\WIN32 directory on the Web server, there should be an ADDONS directory. If there is not one, create it.
2. | Create a directory under the GW7CL\WIN32\ADDONS directory called GWMSGR.
3. | Copy the configured GroupWise Messenger client extractor file called NVLMSGR.EXE from the \Novell\NM\ma\software\client\win32 directory to the GWCLIENT\WIN32\ADDONS\GWMSGR directory on the Web server. Rename the NVLMSGR.EXE file in the GWCLIENT\WIN32\ADDONS\GWMSGR directory to SETUP.EXE.
4. | In the \Novell\NM\ma\software\client\win32 directory, there is a file called ADDON.CFG. Copy this file to the SDD\CLIENT\WIN32\ADDONS\GWMSGR directory.

When users run the SETUP.EXE file from the SDD\CLIENT\WIN32 directory, it will install the GroupWise Windows client, and it will automatically run the GroupWise Messenger installation.

Note

You do not need to regenerate the SETUPIP.EXE file in order for this installation method to work.

There are some additional methods for installing the GroupWise Messenger client. You can distribute the NVLMSGR.EXE through a mail message, and tell users to right-click the attachment and select Open. You can also put the NVLMSGR.EXE file on a website that your organization already has configured.


Summary

A GroupWise Messenger system can get very elaborate. The online documentation at www.novell.com/documentation will give you plenty of instruction on how to configure your GroupWise Messenger system. This chapter went further than that and exposed you to solutions and some real-world issues that the online documentation does not cover.


Part VI: Solutions

30 Creating a Secure Messaging Solution

31 Creating a Highly Available GroupWise WebAccess Solution

32 Creating a Highly Available GroupWise Internet Agent Solution

33 Creating Solutions to Limit Post Office Message Store Size

34 Creating a GroupWise-to-GroupWise Communication Solution Across the Internet


Chapter 30. Creating a Secure Messaging Solution

Hundreds of millions of emails per day (according to some, soon even billions) are being sent through the Internet via Simple Mail Transfer Protocol (SMTP). This protocol is indeed quite simple, especially when capturing and reading the information embedded in the message, thereby allowing you to access all kinds of valuable business information.

Take a look at your own GroupWise environment. Any GroupWise administrator can easily copy incoming or outgoing messages from the GWIA Sent or Received directories, read the message, and convert the attachment to its original format. Although this admin-ability might not be seen as a big issue, anybody on the Internet who can intercept your Internet traffic can capture your SMTP sessions and do the same. Figure 30.1 shows the vulnerability of SMTP sessions on the Internet.

Figure 30.1. SMTP is not secure; messages are easily readable because the SMTP session is in clear text

Somewhere in the near future, somebody within your organization or within a recipient's organization is going to realize the impact of this security holeand then will want you to fix it!


So Do We Need to Fix This Problem?

A growing number of organizations should already be implementing secure messaging solutions. For example, sending medical information regarding patients by regular Internet mail should not be legal. Other high-risk or high-security organizations, such as government agencies and financial institutions, are implementing policies to reduce or even remove the risk of information getting into the wrong hands.

Even as a private citizen, you should wonder what kind of information you're unwittingly sharing with the Internet community via SMTP. It's really a bit like sharing all your private files on your hard disk with the entire Internet community, isn't it?

This chapter provides you with the details of secure messaging, especially as regards GroupWise. And really, in the end it isn't as complicated as it might look now. This chapter discusses some general ideas and techniques for securing your email messages and then focuses on an important technique called Secure MIME (S/MIME). For more information on secure messaging, try Secure Messaging with PGP and S/MIME, written by Rolf Oppliger; it's really a bit like a Swiss army knife on this subject (and he's actually from Switzerland). It's not an easy read, but it is very concise and is probably the only book that covers both PGP and S/MIME in depth. Be sure to take a look at the reference lists at the end of the chapter for more information.


Information Is Leaking Out When Email Is Sent Across the Internet

You face two separate problems when sending emails via the Internet. The most well-known problem involves the unencrypted nature of SMTP. The other problem is probably as big and ugly: identity spoofing, or hijacking, as shown in Figure 30.2.

Figure 30.2. SMTP incorporates two problems: identity spoofing and clear-text messages

[View full size image]

So now we have two problems to solve:

  • Reading of unencrypted emails: By simply collecting IP packets, anybody with the right tools can capture a complete SMTP session and easily read the plain ASCII information. The attachment will have to be converted from MIME-encoded format to its native file format, but this is an easy task with so many tools available. Quite often, the local email client can handle the conversion task.

  • Identity spoofing or hijacking: It's also rather easy to send an email on behalf of somebody else. Just use your own SMTP server and add another Internet domain. Many recipients' sites will accept these kind of emails. In a world where more and more transactions and information exchanges are conducted via Internet email, it's spooky to realize how simple it is to hijack somebody's email identity.

Surprisingly, as shown in the next section, there are several ways to tackle the first problem, but these are more or less worthless if you don't tackle the much-more-difficult second problem.


Overview of How to Secure Messages

There are several ways to solve the problems mentioned previously. Let's take a rather high-level look at some of these solutions:

  • Non-SMTP system connections: Use GroupWise-to-GroupWise or GroupWisetoforeign systems connections, effectively removing the need to use the SMTP protocol. Chapter 15, "Administering Multiple GroupWise Systems," and Chapter 34, "Creating a GroupWise-to-GroupWise Communication Solution Across the Internet," explain how to accomplish this task.

  • Secure SMTP: Use Secure SMTP to set up a SSL-ized SMTP session between two SMTP servers, thereby creating a secure SMTP channel without any user intervention.

  • Web-based systems: The sender's message is captured by an appliance, and a secured HTML link is sent instead to the recipient. An example of such a product is Message Protect from IntelliReach (www.intellireach.com).

  • Securing individual messages: Use specialized additions to SMTP such as PGP or S/MIME to secure individual messages, which requires end-user participation.

These are just some of the solutions; there may well be others.

Non-SMTP System Connections

A GroupWise environment is internally secure from day one after setup. Security has always been one of the most important features of GroupWise, and there is really no way a normal end user or even a big-time hacker could simply access items in the message stream or the message store. Every bit of information in the message store is encrypted, and messages sent between post offices via domains are encrypted with a proprietary 40-bit encryption. And as described in Chapter 27, "Securing Your GroupWise System via SSL," GroupWise offers the capability to enhance this security by using 128-bit SSL encryption between all GroupWise components. Figure 30.3 shows how two GroupWise systems can speak securely to one another over the Internet.

Figure 30.3. GroupWise-to-GroupWise connections via the Internet can be secure with SSL

[View full size image]

Predefined GroupWise-to-GroupWise Connections

If both the sending and the receiving environments are GroupWise systems, you can easily configure a foreign domain connection, enabling these environments to transfer messages directly via MTA-to-MTA connection. The advantage of a predefined link is that you can also exchange address book information automatically. Setting up such a link is fairly simple and is described in Chapter 15, "Administering Multiple GroupWise Systems."

Auto-Detected GroupWise-to-GroupWise Connections

Even without a predefined connection, an MTA-to-MTA connection can be established automatically, because with version 5.x, Novell can use Dynamic Internet Link to detect the possibility of connecting to a foreign MTA. If you put the right information in the DNS, your MTA will be able to connect to a foreign MTA and exchange native GroupWise messages, which are of course encrypted by default. You can find more information in Chapter 34.

Predefined GroupWisetoForeign Systems

Another alternative for delivering secure and identity-checked emails is to use a high-level gateway between the two disparate systems, for example, from the GroupWise Gateway to Exchange or Domino. Although the tools are there and are relatively easy to set up, this will require diligent research and information exchange with the email administrators at the other side and might therefore be too difficult to implement.

Reality Check

It's not a GroupWise-only world yet! Because so many organizations haven't made the decision yet to implement GroupWise as the best messaging system ever, it's important to cover other ways to solve the secure messaging problem. This chapter focuses mainly on the use of the S/MIME standard, but there are other options as well, such as PGP.

Note

In earlier versions of this book, we also discussed PGP. However, PGP no longer creates solutions specific to third-party clients. Instead, PGP makes an API available for third parties to use if they so desire. At the time this book was written, Novell has not written to the PGP API.

Although these non-SMTP high-level system connections solve the second problem by setting up a secure connection between the systems, not all of them completely solve the first problemmaking sure that the sender's identity is checked. This can really be solved only with the predefined connections, all the while trusting each other's environments to be secured against this kind of fraud.

Securing the SMTP Channel

Theoretically, it would be rather simple to encrypt the complete SMTP session in between two SMTP servers. And the good news is that GroupWise 6.5 and 7 already support this functionality.

The ESMTP, or Enhanced Simple Mail Transfer Protocol, has some options to exchange information regarding capabilities of the two connecting ESMTP servers during the initial handshake. Based on the capabilities of both SMTP servers, the GWIA will refuse to accept SMTP sessions that try to transfer messages of invalid recipients and/or messages above a specified size. The two ESMTP servers can also detect if they both support SSL-ized SMTP sessions and will try to establish an SSL connection to transfer the SMTP message via this secure SSL channel. This protocol is also referred to as StartTLS. Figure 30.4 illustrates how StartTLS is incorporated into SMTP mail.

Figure 30.4. Securing messages via ESMTP and StartTLS

[View full size image]

In a perfect world, this approach would indeed solve at least the second problem, by encrypting the complete SMTP session and thus the email within that session. However, only a very small percentage of the current SMTP servers around the world can support this mechanism or are configured correctly to use it. And even so, you still haven't solved the second problem, because you can't ensure that no one within the sender's environment hijacked a sender's identity (imagine a big university with lots of students mimicking their professors' identity, raising their grades by simply sending some relevant messages).

Enhanced SMTP Can Offer Secure Messaging with StartTLS

With the advent of Enhanced SMTP (ESMTP), we now have the capability of securing Internet mail connections by using SSL or Transport Layer Security (TLS). Our GWIA supports SSL and TLS, and the setup is just as simple as it is for the other agents, as described in Chapter 27. The only issue here is that you have control over only your end of the SMTP transaction. Both ESMTP servers (yours and the one at the other end) must support TLS for messages to get encrypted. After it's set up, your GWIA will send all messages using TLS if the other host supports the protocol; otherwise, the message will be sent using plain SMTP.

Setting Up Secure Messaging with TLS

Well, this is an easy one. In Chapter 27 we explained what you need in order to set up your SSL environment for GroupWise. To make this really work well, there is one thing you need to make sure of: The certificate being used by the GWIA needs to include the hostname as seen from the Internet. Also, the certificate should preferably be signed by an official (external) certificate authority so that the other side can check the validity of the certificate by looking at the trusted root of your certificate. You can find more about how to get such a certificate in Chapter 27. Let's just assume that you have a valid certificate; here are the steps to set it up:

1.
Create a CERT directory off of the Domain\WPGATE\GWIA GATEWAY DIRECTORY.

2.
Store both the *.B64 and the *.KEY file in this directory.

3.
From ConsoleOne, bring up the properties of GWIA, and from the GroupWise tab select SSL Settings.

4.
Complete the fields, specifying the certificate file and key file. (See Figure 30.5.)

Figure 30.5. Specifying the certificate and the key file

[View full size image]

5.
Click on Set Password and enter the case-sensitive password. Click Apply to save the GWIA properties.

6.
From the GroupWise tab for GWIA, select Network Address. Select Enabled under SSL for SMTP. (See Figure 30.6.) Click OK to save the changes and exit the GWIA properties screen.

Figure 30.6. Enabling SSL on the SMTP sessions

[View full size image]

7.
Restart GWIA.

You have now successfully set up secure messaging with TLS.

Test Secure Messaging with TLS

To test for TLS support, use any telnet client you have to verify that your GWIA or any other SMTP host supports TLS. These steps use the Windows 2000 standard telnet client:

1. | Start the telnet client from a DOS command prompt window and issue the command telnet.
2. | From the Microsoft Telnet> prompt, type OPEN Hostname GWIA server 25 (replace Hostname GWIA server with the registered hostname of the SMTP server), and press Enter.
3. | After a few seconds, you should get a response with the identity of the host. Then issue the command EHLO. Depending on your telnet settings, the command you type may not be visible on the screen. If you get the response message 250-STARTTLS, the host supports TLS.

Whenever your GWIA connects to another ESMTP supporting TLS, the ESMTP will be protected by SSL.

Working with Web-Based Systems

When looking at Web-based secure messaging systems, you have to remember that market share is still small. Most solutions are single-vendor solutions. For example, http://www.hushmail.com is a great PGP Web-based solution, but many organizations want to control such Web-based systems within the boundaries of their own IT environments and quite often don't want to host it externally. When you're looking at GroupWise environments, an enhancement of GroupWise WebAccess with PGP capabilities would be far more suitable than such external Web-based solutions.

Note

A few nonmainstream Web mail services offer secure messaging, for example, Hushmail (www.hushmail.com) and Safe-Mail (www.safe-mail.net). Hushmail uses a Java applet to create PGP encrypted email. Safe-Mail offers S/MIME web-based services, including POP support.

Securing Individual Messages

You can see now that most of the other methods don't solve all of your problems. It looks as though you have to involve the users and give them some tools. First, let's take a closer look at the two problems. This section first discusses some details of secure mail solutions.

Encrypted Messages

A message can be encrypted using various techniques; for example, both S/MIME and PGP use private and public keys. The private key is stored in the sender's workstation environment and used to encrypt the message. The recipient can decrypt the message by using the sender's public key, to which she somehow needs to have access. This can be via a kind of lookup mechanism, for example based on LDAP, or by simply exchanging public keys and storing them in the recipient's environment.

A message is encrypted via an algorithm that generates a session key that is combined with the recipient's public key, transferred via the Internet, and decrypted by using the recipient's private key and the session key. This effectively means that as long as the keys aren't compromised, nobody in between the sender and the recipient can have access to the content of the message.

And now you have an interesting problem: Really nobody or nothing, no processes at all, can touch this message, not even the corporate virus or content scanner! These messages will reside within your message store and travel through your message-flow like real untouchables. Both the sender and the receiver will have to rely on desktop virus scanning to process the unencrypted messages whenever the recipient or the sender opens such a message.

The big differences between S/MIME and PGP lie in how keys are generated, how these keys are validated, and where they are stored. We will show more details on how S/MIME handles keys in the upcoming sections.

Digital Signatures

If you want to make sure that the users are who they say they are, you can do some basic checking on receipt of every SMTP message. Because most SMTP servers don't even do a basic reverse address lookup check (as described in Chapter 16, "Internet Addressing"), they really don't have any idea who the originator of a certain message is. Research has shown that most SMTP servers (estimated at 95%) don't even use this simple check. And, yes, if you turn it on in your own environment, you will reject emails from badly configured sender environments, so even if you're aware of the problem you might not be able to use this important feature.

Really, for the intents and purposes here, this check isn't good enough, because although it will make sure that you're connecting to the right SMTP server, you still don't know whether the people on the other end are the lawful owners of the mailbox or whether they are mimicking somebody else at the sending site.

Digital signatures can take away a lot of this discomfort and, if implemented and used properly, can give you an almost 100% certain guarantee that the sender (and the receiver) is genuine. The idea is based on the exchange of public keys and a method to check the validity of these keys against a certificate authority (CA, used by S/MIME and PGP) or a Web-of-Trust (used by PGP). When an email is sent, the digital signature is added on request or automatically, and the receiving email client can use this information to verify the validity of the signature and thus the identity of the sender.

Of course, you should realize that encrypted or digitally signed email cannot be handled by just any email client. For example, Gartner (www.gartner.com) mentions in its whitepaper "Email Encryption: Multiple Strategies Needed" that almost 65% of the business recipients use email software that could be configured to handle S/MIME messages. We will cover this aspect in more detail later.

Three Important Procedures

From an administrative viewpoint, there are actually three important tasks associated with the setup and maintenance of a secure messaging environment. You will have to manage your keys and certificates. These are the tasks you must take care of:

  • Create: Each user should somehow be able to get a copy of his private and public key. These keys are generated either centrally within a directory service in what is called a PKI (Public Key Infrastructure) in S/MIME or individually (PGP).

  • Distribute: After the keys are created, the user must be able to store them in some kind of secret store. S/MIME most often uses the locally installed certificate, for example, the Windows Certificate Store that is an integral part of Internet Explorer and/or Windows 2000/XP. With PGP, this is a so-called PGP key ring.

  • Revoke: It's very important that keys be able to be revoked, either because they're compromised or because they become invalid for other reasons. For example, when users leave the organization, they should not be able to send digitally signed emails on behalf of the organization. Within S/MIME this can be handled by mechanisms like the CRL (Certificate Revocation List) and the newer OCSP (Online Certificate Status Protocol), which are briefly covered later, whereas PGP has some other mechanisms to handle revocation.

With all of these differences and similarities between S/MIME and PGP, it's not so strange that larger organizations implement secure messaging based on S/MIME.


A More Detailed Discussion of S/MIME

With S/MIME the user will use private and public keys to create and verify both signatures and encrypted emails. The certificates used by S/MIME are centrally created and managed. They can be either bought from an external third party such as Verisign, Entrust, Thawte, Globalsign, and various others or created within your own local Certificate Authorityfor example, the Novell Certificate Server, which is almost always an integral part in any environment that runs eDirectory. GroupWise 7 natively supports S/MIME version 3.

The focus in this book is directed mainly at the Novell environment, but whenever possible, other solutions are briefly mentioned as well.

S/MIME Basics: An Overview

GroupWise utilizes other parts of your environment to create and distribute certificates/keys to your users, after which the users have to import their certificates within GroupWise just once. They will then be able to use the certificate for S/MIME, without any additional software needed, as well as have the option to use one or both of the special buttons on the toolbar (see Figure 30.7) to digitally sign and/or encrypt the message.

Figure 30.7. Users can digitally sign or encrypt a message

[View full size image]

The left button with the padlock presents the Encryption option; the right button with the small certificate symbolizes the digital signature. If these buttons are clicked without any preparation having been made, the users will be presented with one of several security errors and warnings.

You will have to prepare your GroupWise environment to be able to send an S/MIME message. We will investigate the details later; let's first have a high-level overview of the process, taken from Rolf Oppliger's book.

Processing Messages: The S/MIME Digital Signature

When sending a digitally signed message, the sender must follow these steps:

1. | The sender uses a one-way hash function to generate a message digest.
2. | The sender encrypts the message digest using one of his private keys (the encrypted message digest represents the digital signature for the MIME entity).
3. | The program prepares a block of sender information that contains the sender's public key certificate, an identifier for the message digest algorithm, an identifier for the public key algorithm (that is used to encrypt the message digest), and the encrypted message digest.
4. | The MIME entity and the block of sender information are concatenated to form a CMS object of the type signed-data.

The resulting message is wrapped in MIME and sent to the recipient.

When the message is sent with a digital signature, the message body is still clear text, but the digital signature is added in a hashed format as application/x-pkcs7-signature:

novell.com 16291
EHLO mail.clarify.nl
*S00001bbe* *Egroupwise.3EF381B1.FA3:a:fa3e:Y* *RH* MAIL
FROM:<erno@clarify.nl>
*NSF* *Osmtp;groupwise-TKRATZER@novell.com:1:1* RCPT
TO:<TKRATZER@novell.com>
DATA
Received: from Clarify-EXT-MTA by mail.clarify.nl
   with Novell_GroupWise; Fri, 20 Jun 2005 21:45:19 +0200
Mime-Version: 1.0
Date: Fri, 20 Jun 2005 21:50:41 +0200
X-Mailer: Groupwise 7.0
Message-ID: <20030620T215041Z_FA3E000A0003@clarify.nl>
From: Erno de Korte<erno@clarify.nl>
Subject: testing digital signature
To: Tay Kratzer<TKRATZER@novell.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7
-signature";
   micalg=sha1; boundary=" IQLVNRRDMANYIVOBVWNJ "

   IQLVNRRDMANYIVOBVWNJ
Content-Type: multipart/mixed; boundary=" RDFXQVUSLTRZHWFEOQYB "

    RDFXQVUSLTRZHWFEOQYB
Content-Type: multipart/alternative; boundary=
"   QBAJWRNHWQNJYAINIUQI "

   QBAJWRNHWQNJYAINIUQI
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Tay,

This message was digitally signed, please verify my signature!

Regards,

ir. Erno de Korte

MCNE/MCNI/MCSE/MCT
M +31-629-016000

    QBAJWRNHWQNJYAINIUQI
Content-Type: multipart/related; boundary=
"   XVYBEATNYECEPBTGWGYB    "

On the recipient's side, two steps must happen:

1. | The recipient must decrypt the digital signature using the sender's appropriate public key, which is extracted from the block of sender information, to reveal the message digest.
2. | The recipient must generate a new message digest for the received message and compare it to the revealed message digest. If the messages' digests match, the digital signature is verified and the message is accepted to be authentic.

If users try to send an S/MIME encrypted message without any preparation, the message won't proceed because the sender doesn't have a certificate with a private key available in his environment. Note that you don't need any information from the recipient for digital signing, because only the sender will add his digital signature, which can be verified by the recipient.

Processing Messages: S/MIME Data Encryption

When sending an encrypted message, the sender must follow these steps:

1. | The sender (pseudo)randomly generates a content-encryption key that is appropriate for the encryption algorithm of choice.
2. | The sender encrypts the MIME entity with the content-encryption key.
3. | For each recipient, the sender encrypts the content-encryption key with the recipient's public key.
4. | For each recipient, the sender prepares a block of recipient information that contains the sender's public key certificate, an identifier of the algorithm used to encrypt the session key, and the encrypted content-encryption key.
5. | The encrypted MIME entity and the block(s) of recipient information are concatenated to form a CMS object encrypted enveloped data (in layman's terms: an encrypted message). In addition, a copy of the content-encryption key should be encrypted for the sender and included in the enveloped data.

The result of this operation is wrapped in MIME and transmitted to the recipient. Note that in step 3, the sender needs the recipient's public key. This key might already be stored in his local secure store or can be harvested using LDAP for example, as you'll see later. For clarity, this example only shows an encrypted message (the Content-Type shows application/x-pkcs7-mime; name=smime.p7m), without a digital signature (of course, these two can also be combined in a single message):

novell.com 16290
EHLO mail.clarify.nl
*S000010e7* *Egroupwise.3EF381C0.FA3:a:fa3e:Y* *RH* MAIL
FROM:<erno@clarify.nl>
*NSF* *Osmtp;groupwise-TKRATZER@novell.com:1:1* RCPT
TO:<TKRATZER@novell.com>
DATA
Received: from Clarify-EXT-MTA by mail.clarify.nl
   with Novell_GroupWise; Fri, 20 Jun 2005 21:45:19 +0200
Mime-Version: 1.0
Date: Fri, 20 Jun 2005 21:50:56 +0200
X-Mailer: Groupwise 7.0
Message-ID: <20030620T215056Z_FA3E000A0003@clarify.nl>
From: Erno de Korte<erno@clarify.nl>
Subject: testing encrypted messages
To: Tay Kratzer<TKRATZER@novell.com>
Content-Type: application/x-pkcs7-mime; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
modification-date="Fri,
   20 Jun 2005 21:50:56 +0200"

MIIKuQYJKoZIhvcNAQcDoIIKqjCCCqYCAQAxggLoMIIBbwIBADBXMDExGjAYBgNV
BAsTEU9yZ2Fu
aXphdGlvbmFsIENBMRMwEQYDVQQKFApXV1dfVFJFRV8xAiICHBHzJSJaIcLGg2Pt
mns3FXV0tnhg
UE2SAGboLx0CAhliMA0GCSqGSIb3DQEBAQUABIIBAA/0pEEc48+k+usk0nw/LN9I
y4VmewRybeoZ
DpjcJu+zY1uUB5x2124/m2c1Q27DSPtBKwwwq8WtO4GtNudwKYLLv8SF2ClA0s1j
PN33VJI0c9Z+
bfMX7NCZZbEXE68WFJwi9GJXs8443tXbKevXqXz+7PHHYZm8kCLNMStPC9tMUosE
GbMOl7OaOB53
wMISn7Q0lm6epPKQqZDDtt5tr32Anpv/dDdJG83hqR6ePL9U09gwMonjAQ3CDe4i
dCSXZT09hdzB
OAbkX8lJzAuqMLVXZ7hjHAdTg8Y/HTlaULMEGVM9kWbJ0jbOCGJb7/gJIiYvGMFV
ijj04BzbXrsP
XG4wggFxAgEAMFkwMzEaMBgGA1UECxMRT3JnYW5pemF0aW9uYWwgQ0ExFTATBgNV
BAoTDENMQVJJ
RlktVFJFRQIiAhwFYsJukGiWEt9VjHJfTYIveoYp1Yv6g5ZOxENnAgIBBzANBgkq
hkiG9w0BAQEF
AASCAQAr/z+hbcGpCplqns7045PHzcncQ5v+Nzxa5aiU2+mIMEJ6LW+UIZJQ+9Ue
9f9HoE1wROCA
baMsljtmWd3mAjiJJbl2VxQdCPIlMBqS5F5el2PlTZJ6mOjoso3Yl7chRfzkx8F/
2Y+j6FXxuuoI
3vWyZ3yjeGEGSYtrt6o1TSVYV+jlbzPPLEWYhcjFGzRHAH+8cbkCoqgGrRqqTFXI
CNrOt4nJnocg
byr6gNbHd1zg6cJWblkHnGd0GyRQNmZ9uX5fgBUyj1jw/nvXYRsgUWR9byOrdMWo
n1m+3Yi5wWhb
es3z+XeVhyitsqVnuso1i4SHprlOHrxN626QXgl4xCx1MIIHswYJKoZIhvcNAQcB
MBoGCCqGSIb3
DQMCMA4CAgCgBAhBu37nJyoiA4CCB4jhpWvaNfcdnMLyiLQwJwAvATBvGTjFpgVk
H2q4VCFnv9b9
xng+SUxHHsFLnyPRffm9G9VTMMrD2/BrFt8E1DfkSfOHuEFK0xMpUvb9YZLx1qk/
zpVESa9teFEp
yx8S/a+UPzCJBfuY8+J+tAO6bzwaYCBHrG9F1Ree7SBr/vprKx00v/aS57wKDB7C
hZgUIlart0No
RIysZ4KDVSgzsDkcytQM8U6g65HjCoW52oE2BCHN0duFm1wDE5WMv8khFtcsVkkr
+h5nkF/fG3k3
WAW5S/NonqbyQw3+OdSw8DLQMNoUu8NsVxXb4BUq/7I4JS9YYbXX88WpQ3tJjJE5
6G2ftKwxcr67
mAOxuGlGfEEmCPHAXxVU66xDQ63oFguEP/6YMgLeue/AL5uodQBYLYyQUGjCyM8y
48D+CMbgQ3il
1IEUhDh2uGyVhzkDCZKjZ2lNZQ2VDUoZi8lqCDLnU7sIsrPoRCHkTsVQujcfeo6F
3pRhwNP1ZbUk
cpuVNKKYDubGmBjWkuaPCXp8evQcB0fDaXSUFwkLOMtlWfrLm3GNG4s/YbVgfGcW
5thYa+LInjqq
Sb9MoUKMkp6eLFLVceTnTuPW1ASO6oOLM28lsoJ+NNHSJoAg/RdscexOSRnwzE4V
abFiJGIuTONk
4quBRN7L6B9Zs8Kfiw1csOK2e3Ewxzqh0WWhBkZXWsie/WNUqE8QLIvsrGKo5uVK
9yMhPEqWuafl
2Re5gkCpvZQSqHvINd18qSHRRrc844/9oCjIkNRdvksrN47sMMzgRUYjJAuWIm4N
FxP1eDlsc0t5
pm+SXxoGUBTzrvbScHpzpyFXU3XMvSeRNM3JePIIYCgjLzblQxQ7i0aY+Q/cBq3o
JxSC5hXZUmDf
wpxk6OsbGovu2TWm0d0qqq+X5TyNoULbxa2O/BTjPF8gs0A7JTxBorlt1WkObno2
Ovg0gnTjDv9l
1UbWvpZKxccf+hFtytMIe8XqeR5UN6jmSlpQ1SoQxj/kHVJHO7G0ft+cjo3Dmscz
XuGGWx5h2GXs
Vxe+ZO+x4JOzlOdOuYFkIlWtZI1JNoaqYp8zc/998p3hCF06vpCNhUaM862A91PE
hIiDla+hu3nz
cWvU7JbS2IsCYsoaMau6I1jTunGjqnACGTqVi4yS7Y2UDZV1e7PqXoR6hL4/deXA
j+x1fEgcjkuk
/54oNS/mTs74cBi2FftEpjMqUHFA4dPgRJSBXcwLBZuRYErtgJCG3D8A8HS7iN/V
kGKfXQ/NlrF6
IQJcCO6+GZxd0yG71g==
.
QUIT

In the preceding example, the message body is sent in a hashed format; only the sender, recipient, and subject are shown in clear text.

On the recipient's side, the procedure to decrypt the MIME entity includes two steps that can be summarized this way:

1. | The recipient decrypts her block of recipient information using her private key.
2. | The recipient decrypts the message content with the session key.

Obviously, the second step reveals the message content of the recipient.

It's important to understand that any S/MIME-compliant email will be able to handle these steps and thus can process the digital signature and/or encrypted message. As Gartner (www.gartner.com) points out, nearly 65% of business recipients use email software that is capable of handling S/MIME, although many aren't configured properly to do so yet.

Preparing Your Environment

You need the following components in order to send secure messages in a Novell GroupWise environment:

  • PKI S/MIME certificates for every user involved, either based on your directory services or bought from commercial vendors. In the case of a complete Novell environment, you need the following:

    • eDirectory 8.6 or higher, which runs on almost any server-platform.

    • Certificate Server 2.0 or higher, which is an integral part of recent eDirectory implementations on almost any server-platform.

    • An LDAP server that's v3.0 compliant, in a Novell environment most commonly provided via the NLDAP NLM, as part of eDirectory. This is optional but will increase user friendliness.

  • An S/MIME-compliant email client, such as GroupWise 7. GroupWise 5.5EP, 6.0, and 6.5 can also digest secure messages; however, the focus of this chapter is on the features of GroupWise 7.

  • A local desktop certificate store, which most likely will be available when the Internet Explorer or Netscape browser is installed. There may be additional certificate stores on your desktop, like the one from Entrust, but it's beyond the scope of this book to discuss this topic. This discussion assumes that IE 5.x or higher is installed and that the associated certificate store is functioning properly, as shown in Figure 30.8. More info on this subject can be found at the end of this chapter.

    Figure 30.8. An example of a standard Windows 2000 environment with several security service providers

    [View full size image]

Note

Although it's perfectly feasible to install these browsers on the Windows 9x environment, experience has shown that the certificates stored on Windows 2000 or higher are far more stable than those on earlier versions. A corrupt certificate store will most likely have to be reinstalled and all certificates might need to be imported again.

Because all information is stored in the Windows environment, you should consider using a roaming user strategy, as offered by ZENworks (for example); otherwise, the users will have to add the same information to the certificate store on any desktop they work on.

  • ConsoleOne with the correct snap-ins, preferably version 1.3.6 or higher, with the snap-ins for both GroupWise 7 and the Certificate Server. The admin workstation will also need to have a recent NICI client installed, which is all part of the normal eDirectory 8.6.2 or higher install process.

  • GroupWise system without aliases. The GroupWise aliases aren't properly transferred into eDirectory (in fact, they're not transferred automatically at all). If you use aliases, you need the correct info in eDirectory. The eDirectory Email address field is being used to create the user certificate and/or for lookups via LDAP, so you have to get rid of the Gateway aliases and use the GroupWise 6.5 and 7 Free Form Internet Address field instead, as discussed in Chapter 16.

  • A proper firewall and DNS configuration that allows your senders to connect to external LDAP servers, as well as allowing external parties to collect public key info from your LDAP server. This is optional. Quite often you will also want to define an extra DNS entry like ldap.novell.com, which will be easier than having to use the IP number of your (public) LDAP server.

  • An LDAP browser, recommended only for the administrator, to test the LDAP connection.

Most environments don't need anything extra to start sending S/MIME messages!

Note

Although using LDAP is optional, you will still need to make sure that all eDirectory user objects are properly filled in. It's especially important that the eDirectory field Email Address is properly filled in before the user certificate is generated, because the email address will be embedded in the certificate info. Unfortunately, this is especially important if you use GroupWise gateway aliases, because normally these will not be filled into the proper eDirectory field. In general, it's not recommended to use gateway aliases with version 6.5 or 7, which has the FreeForm Internet Address field with some other advantages, as described in Chapter 16.

The requirements for S/MIME are generally not that difficult. Most customer environments have the S/MIME requirements already fulfilled.

Configuring Your Environment

The following eight steps show you how to prepare your environment for sending and receiving S/MIME messages. Step 1 describes an administrative procedure needed for every user; steps 2 and 3 need to be performed by the users before they can send an S/MIME message. Steps 1 and 2 can be skipped if you're using commercial certificates.

In step 4, you will be able to send your first digitally signed S/MIME message; step 5 demonstrates how to use LDAP lookup of public keys. Step 6 demonstrates what will happen if you receive and open a digitally signed message. Step 7 shows you how to send an encrypted S/MIME message. In step 8, you'll open such a message at the receiving side.

Step 1: Checking User Objects and Creating User Certificates in Your eDirectory Tree

Figure 30.9 shows the tabs for checking properties and configuring. Follow these steps to create certificates for eDirectory users:

Figure 30.9. ConsoleOnechecking properties and configuration tabs

[View full size image]

1.
Open the General tab and verify the email address in the E-Mail Address field.

Note

As mentioned before, when you're using gateway aliases this information might not be filled correctly; as a general recommendation, first move away from gateway aliases to the new FreeForm Internet Addressing format before starting to use S/MIME.

2.
Click the Security tab.

3.
If a user certificate is already present, make sure that it was generated with the correct email address embedded in the certificate. Also make sure that the certificate is not expired.

Note

Do not replace the user certificate with wrong or old information without making sure that the user doesn't use it for something else. Creating a new user certificate will most of the time invalidate the old certificate.

4.
If it's not yet present, generate the certificate by using the Create button. You will be presented with the screen shown in Figure 30.10.

Figure 30.10. ConsoleOnespecifying a user-friendly certificate name

[View full size image]

5.
Specify a certificate nickname, preferably something user friendly, because this will be the default name that will be presented when the users save their certificates.

6.
You can leave the creation method set to standard, which will create a certificate as needed. Click Next and you will see a screen similar to the one shown in Figure 30.11.

Figure 30.11. ConsoleOnea summary of creating a user certificate

[View full size image]

Check the information in the summary screen, especially the email address field and the expiration date, and click Finish to create the certificate.

Here are some important notes:

  • This certificate will contain both the private and the public key information for this user. However, as an administrator, you're not allowed to export the private key of any user object, other than your own account. You can use the export function only to export the public key.

  • Keys are stored in Novell Certificate Server's secrets store in eDirectory and are therefore available to the user any time, any place. It's generally not recommended to let the user create a copy of the private key and store it in the file system, because this might compromise security. However, as you will see, you need a (temporary) copy of the private key to import into the user's desktop secret store. Currently, there is no way (yet) for GroupWise to access the certificates directly in eDirectory. However, Novell is considering creating a direct connection between GroupWise and Certificate Server as soon as all the APIs are available.

  • The secret store within eDirectory can be used to safely store and distribute any PKI certificate, which might include commercially generated certificates from Verisign, Globalsign, and others, as shown in the next step. As discussed, even PGP keys can be stored in eDirectory if the schema is properly extended. For more information, check the Novell online documentation.

The user's certificate is now created in eDirectory. GroupWise does not read certificates out of eDirectory, so the certificate must be exported. The next step explains how to do this.

Step 2: Exporting the Certificate from the eDirectory

Individua l users must export their own certificate from eDirectory. Making that happen may prove to be tricky, though. At one time Novell created a simple-to-use utility called Novell Certificate Console to export its certificate from eDirectory. This tool can be found on some NetWare servers in the SYS:PUBLIC\MGMT\CERTCONSOLE\BIN directory. Although you may still find the utility, it may or may not work in your environment, because it is no longer being actively developed. Give it a try based on the instructions in this chapter. If it works, great; if it doesn't, you will need to use iManager to allow users to export their certificate from eDirectory.

Follow these specific steps to export a certificate from eDirectory using the Certificate Console utility:

1.
Be sure to log in to eDirectory as a user who will be using S/MIME. Of course, in most cases this will mean you will have to ask the user to log in himself, because normally you should not be allowed to know the user's password.

Note

As an administrator, you can obviously not export the private key of one of your users. For security reasons, only a user with a valid eDirectory login can access the private key material. If you try to export a user's key material while logged in as an administrator, you will be able to export only the public key material.

2.
Browse to the correct location to find CertCnsl.exe or click your ZENworks object to open the Novell Certificate Console, shown in Figure 30.12.

Figure 30.12. Certificate Consolemake sure that the correct tree is selected and the private key is present

[View full size image]

Note

There have been reports indicating that Certificate Console doesn't run on every workstation. In the rare case, this might happen in your environment; just rename the (unneeded) module SYMCJIT.DLL in the \CERTCONSOLE\BIN directory and it should run fine.

As shown in this screen, this user has imported some additional certificates into eDirectory, so you need to make sure that you export the correct private key.

3.
Make sure that you're connected to the right tree by checking the Current Connection. Check the Private Key Status column to make sure that your private key is available.

4.
Select the appropriate certificate and click Export. You'll see the screen shown in Figure 30.13.

Figure 30.13. Certificate Consoleexporting the private key

[View full size image]

5.
In this case, you do want to export the private key, so click Next and you will see the screen shown in Figure 30.14.

Figure 30.14. Certificate Consoleincluding the certificates in the certification path

[View full size image]

6.
Make sure that the check box called Include Available Certificates in Certification Path is checked; this will export the certificates from your Certificate Authority as well. Choose a proper file location, enter a secret password (sometimes called the passphrase), and click Next.

7.
A summary screen will appear. Click Finish to export the certificate to a file.

A user can also use iManager to export the user certificate, including the private key. The advantage of iManager is that this is a web-based tool, so you can basically use any modern browser to accomplish this task. The slight disadvantage is that a user will need to access the iManager framework. If we don't tune that slightly, the user might either be overwhelmed by the many options that this environment has to offer or see no tasks at all. This all has to do with the fact that the tasks within iManager can be configured by Role Based Management, a very powerful set of tools to assign just the right tasks to the right users. If iManager is configured properly, the user will only see what he needs to see.

If iManager is configured properly, the user might only see the View My Certificates option, and if he opens that he will see the screen shown in Figure 30.15. The options offered on this screen are almost the same as those in the Certificate Console described in elsewhere in this chapter.

Figure 30.15. Options the user sees through iManager

[View full size image]

Follow these steps to export a certificate from eDirectory using iManager:

1.
In a supported Web browser, type the following in the Address (URL) field:

http://server_IP_address/nps/iManager.html

You might be redirected to an HTTPS secure page.

Tip

This URL is case-sensitive!

2.
Log in with your username, password, and eDirectory tree name. You can substitute the IP address of an eDirectory server for the tree name.

Note

As an administrator, you obviously cannot export the private key of one of your users. For security reasons, only a user with a valid eDirectory login can access the private key material. If you try to export a user's key material while logged in as an administrator, you will be able to export only the public key material.

3.
On the welcome screen, from the left section called Roles and Tasks, select View My Certificates. You should be directed to the same web page shown in Figure 30.15.

As shown on this web page, this user has imported some additional certificates into eDirectory, so you need to make sure that you export the correct private key.

4.
Check the Private Key Status column to make sure that your private key is available.

5.
Select the appropriate certificate and click Export. You will be asked whether you want to export the private key.

6.
In this case, you do want to export the private key, so click Next and you will see the screen shown in Figure 30.16.

Figure 30.16. Using iManager to include the certificates in the certification path and entering the password

[View full size image]

7.
Make sure that the check box called Include All Certificates in the Certification Path If Available is checked; this will export the certificates from your Certificate Authority as well. Enter a secret password (sometimes called the passphrase), and click Next.

8.
On the next screen, you will be given the option to Export the Certificate into the Browser or to Save the Exported Certificate to a file. You need the certificate in a file, so be sure to select the second option. Depending on your browser, you might get additional screens to save the certificate at the proper location.

The user's private key has to be guarded carefully, and the file system might not be the proper place to store this certificate permanently. You should consider permanently deleting this (temporary) file after the next step. Your certificate information will still be safely stored in eDirectory and available any time and any place. However, bear in mind that if the users step away from their desks and their computers are still logged in, anybody can access the desktop and easily use the local certificate store to send secure email on behalf of the users.

Step 3: Importing the Certificate in GroupWise

This step imports the certificate with private key information into the local Windows desktop certificate store. This process does not require you to exit from the GroupWise interface to access the certificate store. As mentioned, the certificate can come from any source, either from your own eDirectory tree or from a vendor. Here are the actions for you to take:

1.
Within the GroupWise client, click Tools, Options, Certificates, Import, and you'll see the screen shown in Figure 30.17.

Figure 30.17. Importing the certificate into the local certificate store

[View full size image]

2.
Browse to the location where you've (temporarily) stored your certificate, enter the password, and click OK. This will import the certificate in the local certificate store.

Note

In environments in which high security is a major concern, you might want to enable Set Strong Private Key Protection. This way, users are prompted for their secret passwords/passphrases every time they use the private key.

3.
If this is the first certificate you accept in this local certificate store for this organization, you will probably be asked whether you want to accept an organizational certificate in the root store, as shown in Figure 30.18.

Figure 30.18. Accepting a new root certificate into the local certificate store

[View full size image]

Note

Novell uses a root certificate for the complete tree, which is used as a basis to create all other server and user certificates. Ideally, you need only one root certificate for your complete organization, which greatly reduces costs and gives you an enormous flexibility. Unfortunately, most commercial root-certificate vendors, such as Verisign, can issue only server or user certificates, which can't be used as a root certificate for your tree. The disadvantage of not having a commercially based root certificate lies in the fact that other organizations can't validate your organization's certificate against an external trusted party. The only current solution is to exchange root certificates and add them to the local certificate store, more or less the same procedure as you've just done by accepting the self-issued root certificate. Novell is currently investigating this problem and negotiating with several vendors to solve this issue.

4.
Be sure to check the Expiration column and then click the Set As Default button, as shown in Figure 30.19. Otherwise, the GroupWise client doesn't know which certificate it needs to use, even if there is currently only one. A green check mark will appear next to the default certificate. Bear in mind that when several users are using this desktop, there might be more than one certificate in the local certificate store, so a clear Certificate Name will help to identify which certificate to use.

Figure 30.19. Imported certificatemake sure that the expiration date is valid

[View full size image]

Besides the Import button, there is also a Get Certificate button. By default, clicking this button will direct you to a Novell Web page with instructions about how to get a certificate. You might want to consider changing this default behavior by changing an option in ConsoleOne. Right-click any domain, post office, or user object, and then choose Client Options, Send Options, Security. Enter an alternative location on your intranet in the URL for Certificate Download field that can present to-the-point information to your users.

When you use the newest version of Certificate Server, as delivered with NetWare 6.5, you might also consider pointing this button to iManager so that users can export their certificates after logging in. In the future, Novell is considering integrating newer versions of Certificate Server and GroupWise more closely via this button, enabling you to directly import the certificate from eDirectory into GroupWise.

Note

This book is really an admin guide, so it doesn't cover every step for sending and receiving S/MIME messages. There is an excellent Appnote available at the Novell Web site; the second part of this Appnote includes a user guide at http://developer.novell.com/research/appnotes/2003/may/02/a030502.htm.

There is also some excellent user information available in the Novell online documentation (more info at the end of this chapter).

Step 4: Sending the First Digitally Signed S/MIME Message

You are now ready to send your first S/MIME message, by following these instructions:

  1. Create a new message, choose any recipient, add a subject and some body text, and make sure that your message view is big enough to see all the buttons.

  2. Activate the Digitally Sign button and click Send. That's all! How more user friendly do you want it?

Note

Remember, this was a digitally signed message, so the content is not encrypted. However, the recipient can now verify that the sender is who she says she is, so you've solved one of the earlier problems, the identity-spoofing problem.

If you get a warning that indicates that you haven't specified a default certificate, you might have forgotten to use the Set As Default button when importing the certificate. Review "Step 3, Importing the Certificate in GroupWise," to correct this mistake.

Note

Before you can send your first encrypted message, you need some additional information. Remember, you're going to use the recipient's public key to encrypt the message, but you don't have this key yet. If you try to send a message to somebody without having the recipient's public key, you will get a message like the one shown in Figure 30.20.

Figure 30.20. The dialog box you get in GroupWise when sending encrypted messageswhen no public key is found for the recipient

[View full size image]

Simply put, you can use several methods to get this information. Two of the most obvious methods are as described here:

  • Public key exchange: You exchange the public key via email or some other medium. Make sure that you know where this public key is coming from, which can be partly determined by the digital signature, and store the key in your local certificate store. You might end up with a large number of keys in your local certificate store and will have to make sure that they're properly transferred to other desktops you will be working on.

  • Automatic public key retrieval: You use a mechanism like LDAP to automatically retrieve the public key of the recipient. You will need some additional configuration in your environment, but in the end every recipient of these configured sources is automatically included. The Find Certificate button can find the information via LDAP in the recipient's environment.

You likely want as much automation as possible, so let's dive into the second option first. You will have to make sure that you can read the LDAP information from the recipient's side. The LDAP information should contain the public key information. For the first task you can use the normal GroupWise LDAP address book option, but for the second task, it's better to use a full LDAP client (shown in Figure 30.21), like the ones from Novell or Softerra.

Figure 30.21. Softerra LDAP clientverifying the availability of public key material via LDAP

[View full size image]

Note

Figure 30.21, taken from the Softerra LDAP client, shows the user object on the left side and the public key user info on the right side.

Step 5: Sending an Encrypted S/MIME Message with LDAP Public Key Lookup

You now need to configure the GroupWise client to use the LDAP Search Public Key option:

  1. From within the GroupWise client, click Tools, Options, Send, Security, Advanced Options, to get to the window shown in Figure 30.22.

    Figure 30.22. GroupWise clientadvanced optionsactivating the search via the LDAP option

    [View full size image]

  2. There are many interesting options on this page; the one you need to enable is the second option, called Search for Recipient Encryption Certificates in the Default LDAP Directory. This option is not checked by default; make sure that this option is checked. Click OK twice.

If you now add the recipient's environment to the GroupWise LDAP address book and set this as the default LDAP address book, everything will run nice and smooth. Follow these steps:

1. | In the GroupWise address book, go to the Novell LDAP address book and click Directories.
2. | You will see a list of defined LDAP address books (if any). Click Add to add an entry for your new recipient's environment. Enter a descriptive name on the first screen and click Next.
3. | For this kind of information, most LDAP servers don't require you to log in, so you can just fill in the DNS name or IP address of the server and click Finish.
4. | After returning to the list of defined LDAP servers, don't forget to use the Set Default button to point at the most-often-used LDAP source. Click Close.
5. | You can now test your LDAP connection and should be able to get the same kind of information you've previously seen in your LDAP client.
6. | You can now try to send your first encrypted message by addressing anyone in the recipient's environment with a valid certificate.

If everything is set up correctly, things will work like a charm. All the user has to do is click the Digitally Signed or Encrypt button to get things moving. Remember that the message was encrypted with the recipient's public key, so as long as the recipient's local certificate store is initialized with the correct private key from the same keypair, the message will open much like a normal message. The only difference is the little icon in front of the message in the message list and the same icon in the message itself.

This way, everything is set up and functioning correctly. Encryption becomes so easy that it can even become the default setting for every email message.

Note

The advantage of this method is that the certificate is checked every time a message is sent. A second advantage is that any recipient with a valid public key can now receive encrypted email; there's no need to configure anything extra. However, the client will have to connect to LDAP every time. Depending on your situation, the response when clicking the Sent button might be almost instantaneous or a bit slower than normal. Furthermore, when accepting a digitally signed message, the certificate will be stored in the local certificate store, making it unnecessary to use the online LDAP check. And, of course, disconnected clients can't use the LDAP lookup and will have to rely on the local certificate store, which we will investigate next.

So what's going to happen if the recipient's side is not the default LDAP address book? The client won't be able to perform the lookup automatically (bear in mind that it could be a long list of LDAP servers) and will prompt for additional information, as shown in Figure 30.23.

Figure 30.23. Sending encrypted messages without a default LDAP address book

[View full size image]

Follow these steps to find a user's public certificate from an LDAP server:

1.
Click the Find Certificate button. The screen shown in Figure 30.24 will appear.

Figure 30.24. Using LDAP lookupspecifying search parameters

[View full size image]

2.
By default, the Local Certificate Store will be selected, but if you select the correct Search Base this can easily be changed in any of the defined LDAP servers. The E-Mail Address field is already filled in; however, clicking the Search button will deliver no result.

Warning

There seems to be an issue with the Display Name field. By default, an asterisk is placed into this search field; however, quite often the LDAP server will not give any results with this entry. When the asterisk is removed, the results are presented correctly.

3.
Select the correct certificate, if there is more than one, and click Select. The message should now be sent directly.

Note

You don't have to set up anything to receive a digitally signed message; the only thing we need is a correctly functioning local certificate store.

Step 6:Opening a Digitally Signed S/MIME Message

Just opening a digitally signed message from a new sender will present you with the screen shown in Figure 30.25.

Figure 30.25. Receiving a digitally signed message from an untrusted recipient

[View full size image]

Follow these steps to accept a previously unreceived certificate:

1.
You can click Continue to open the message, because it's not encrypted, but the next time you open this or another message from the same sender, the pop-up will reappear.

2.
You can click the various tabs to see more of the info of this certificate, which for example will inform you that the embedded email address is the same as the sender's email. Another tab will inform you of the revocations status, and you will have the option of checking the revocation status.

Note

With the Certificate Server 2.0, which was shipped with eDirectory 8.7 and earlier, it's not possible to use the revocation option for self-issued certificates, because these certificates are taken from your eDirectory and can't be compared against a Certificate Revocation List (CRL) or an OCSP server. The version of Certificate Server 2.52 that accompanies NetWare 6.5 does have the CRL option. Novell is currently working on implementing the more modern OCSP in the next version of Certificate Server. You can check the revocation of most of the commercial certificates if you're online, because most of these certificates will have the necessary information embedded in the certificate.

3.
If you've verified that this is a message from a trusted source, for example by calling the sender by phone, you can easily change the trust level of this certificate. Click the Signing/Encryption Certificate tab. You will have the option to Modify Trust or check the Certification path. This last button will present you with the complete certificate chain, as shown in Figure 30.26.

Figure 30.26. Determining the certification path

[View full size image]

4.
If you're sure that this message comes from a trusted source, you can select the Organizational CA entry and modify the trust for the complete tree. This way, all future certificates coming from this sender's organization will have a valid root certificate. Acceptance of this certificate will have to be confirmed in the next screen. Recall that after such a root certificate is accepted, any other user certificate coming from the same source will be validated automatically.

A very interesting improvement in GroupWise is the way these user certificates are presented to the users. In previous versions and most other email applications, all the recipients will be presented in a long list, with possibly thousands of entries for every possible recipient you're communicating with. The address book of version 6.5 and 7 will sort all these entries and present them in a special Certificate tab, shown in Figure 30.27, associated with the user object in the address book. This new feature makes the management of those certificates very neat and user friendly.

Figure 30.27. Using the GroupWise address book to view the details of the user certificate

[View full size image]

Tip

On purpose, we showed you one more nasty detail in Figure 30.27: The certificate from this user is expired on 2/2/2005 and therefore cannot be used anymore. This is another detail you will have to discuss with your help desk and your end users. Certificates do have an expiration date and will behave much like spoiled milk when used after this date.

When this certificate is accepted, every digitally signed message will be automatically accepted, without any pop-up screens.

Note

Because you've just accepted the public key from a user, you don't need LDAP anymore. Your own local certificate store now knows how to encrypt messages directed at this user, so sending encrypted email will be very easy.

Step 7: Sending an Encrypted S/MIME Message with an Exchanged Public Key

This really is going to be an easy job; everything is set up to go! Because you've received a digitally signed message and accepted the user's public key, GroupWise will be able to find all the information it needs to send the message. Just try to send anything encrypted to anybody from whom you've accepted the public key and no questions will be asked.

Of course, if you didn't get a digitally signed message from a recipient yet, you will have to rely on LDAP or exchange keys first. Remember, encrypted messages cannot be sent without the recipient's public key.

Note

Remember that the sender will have used your public key, so the only thing you need is your corresponding private key, which is probably already in your local certificate store by now.

Step 8: Opening an Encrypted S/MIME Message

You can recognize an encrypted message by the icon in the message list and the icon on the subject bar, as shown in Figure 30.28. By clicking this icon you will get additional decryption information.

Figure 30.28. After opening an encrypted message, you can easily see that it was encrypted, in the upper-right corner of the message window

[View full size image]

If for whatever reason your local certificate store doesn't contain your private key, you won't be able to open the message, and the warning shown in Figure 30.29 will be displayed. If this happens, you need to import the correct private key again (step 3) and you will be back in business.

Figure 30.29. A security error appears when there is no private key in the local certificate store

Combining Encryption and Digitally Signing S/MIME Messages

If everything is set up as described before, you can easily combine digitally signing and encryption by just using the correct buttons, as long as you have the right keys available or if GroupWise can find them via LDAP.

Summary: What Do You Need to Do?

Regarding sending and receiving digitally signed and encrypted messages, always remember:

  • As a sender, you need your own private key to digitally sign a message.

  • As a sender, you need the recipient's public key to send an encrypted message, by exchanging keys, using LDAP lookup, or having the recipient send you a signed message so that you can accept the recipient's public key (and you will need your private key in the local certificate store as well).

  • As a recipient, you need your own private key to decrypt a received message, which is encrypted with your public key by the sender.

  • As a recipient, you can open any digitally signed message without any additional key material, but you should make sure somehow that such a message is coming from a trusted source before changing the trust level.

Here are some other points to bear in mind:

  • Checking the validity and the revocation of a key is (currently) a recipient's responsibility. This can be done either with Certificate Revocation Lists or with the more modern online OCSP protocol. For more info on these protocols, take a look at the URLs at the end of the chapter.

  • As mentioned, only the users are allowed to handle their private keys. Within the Novell Certificate Console, ConsoleOne, and iManager, the administrator can export the public key material from any user but himself.

  • The eDirectory Email Address field must be properly filled in. GroupWise gateway aliases should be avoided when S/MIME is implemented. Because these aren't properly represented within the eDirectory and user certificates, they might contain the wrong email address.

  • The certificate store on Windows 2000 and higher appears to be far more stable than Windows 9x, which also seems to be more vulnerable for security breaches.

  • When properly set up, the S/MIME solution in GroupWise is exceptionally user friendly. User training might be limited; however, the help desk should really understand the issues and must be thoroughly trained.

The GlobalCerts Solution: The Easy Way Out

The GlobalCerts (formerly: Tovaris) SecureMail Gateway is plug-and-play email security. It's truly a unique approach to PKI-enabled secure email. The strength of GlobalCerts's design philosophy and the great flexibility of GlobalCerts's proxy server/network appliance approach enable the GlobalCerts SecureMail Gateway to integrate seamlessly with a wide variety of applications and architectures. For more info, go to www.globalcerts.net.


For More Information on Secure Messaging

Some recommended reading follows:

  • E-Mail Encryption: Multiple Strategies Needed, Gartner, J. Graff, September 13, 2002.

  • Secure Messaging with PGP and S/MIME, Rolf Oppliger, Artech, ISBN 1-58053-161-X.

  • Digital Certificates, Applied Internet Security, Fegghi, Fegghi, and Williams, ISBN 0-201-30980-7.

  • Understanding PKI, Carlisle Adams and Steve Lloyd, ISBN 0-672-32391-5.

  • Secure Email: Innovation Strong, Interoperability Weak, Burton Group, James Kobielus, June 3, 2003.

Check out these relevant Internet standards:

  • PGPRFC2440, the RFC for the "OpenPGP Message Format," located at http://www.ietf.org/rfc/rfc2440.txt.

  • S/MIME standards at http://www.ietf.org/rfc/rfc2633.txt and http://www.ietf.org/rfc/rfc2634.txt.

  • OCSP standards at http://www.ietf.org/rfc/rfc2560.txt.

  • CRL standards at http://www.ietf.org/rfc/rfc3280.txt.

Here are some S/MIME-related links:

  • For S/MIME interoperability testing, go to http://www.rsasecurity.com/standards/sMIME/interop_center.html.

  • For information on using S/MIME email, go to http://www.dartmouth.edu/~pkilab/pages/Using_SMIME_email.html#Intro.

Here are some PGP-related links:

  • The home page of PGP Corporation is http://www.pgp.com.

  • The home page of the OpenPGP alliance is http://www.openpgp.org/.

For Novell products and relevant articles, try these:

  • Tay Kratzer's Appnote "Sending Secure and Encrypted Messages with GroupWise," found at http://www.novell.com/coolsolutions/gwmag/features/a_send_secure_messages_appnote_gw.html.

  • GroupWise User Guide on S/MIME, by Tay Kratzer, found at http://developer.novell.com/research/downloads.htm.

  • GroupWise DocumentationUser Guide on S/MIME, found at http://www.novell.com/documentation/lg/gw6/index.html?page=/documentation/lg/gw6/gw6_userguide/data/aaqe1hd.html.

  • Novell Certificate Serverproduct information, found at http://www.novell.com/products/certserver/.

  • To download the Novell Certificate Console, go to http://download.novell.com. Choose the Certificate Server product and click Submit Search. Download version 2.0 on NetWare and extract the resulting CERTSERV.EXE to a directory. Locate the directory called ../files/PKIPUBLICFILES/CERTCONSOLE and use SETUP.EXE to install Certificate Console (CERTCNSL.EXE) to a network directory.

  • For the Novell user documentation regarding S/MIME messages, go to http://www.novell.com/documentation/lg/gw65/gw65_userwin/data/aaqe1hd.html.

For information about LDAP browsers, try these sites:

  • For Softerra, go to www.softerra.com or www.ldapbrowser.com.

  • For Novell Developer, go to http://www.novell.com/coolsolutions/tools/1283.html.

Check out these commercial certification vendors:

  • For Verisign, go to www.verisign.com.

  • For Thawte, go to www.thawte.com.

  • For Globalsign, go to www.globalsign.com.

  • For Entrust, go to http://www.novell.com/coolsolutions/gwmag/html/a_in_entrust_we_trust_gw.html.

  • For Comodo, go to www.instantssl.com.


Summary

This chapter discussed how to send messages using the popular encryption method S/MIME. It also provided you with the details of secure messaging, especially as regards GroupWise. Some general ideas and techniques for securing your email messages were discussed as well.


Chapter 31. Creating a Highly Available GroupWise WebAccess Solution

This chapter is designed for customers who rely heavily on GroupWise WebAccess. The new GroupWise 7 WebAccess client is so well received that we believe that GroupWise WebAccess will become a more significant client in many organizations. As such, we wrote this chapter so that your GroupWise WebAccess system has all the advantages implemented to make sure that it is always available to your end users.


High-Availability/Distributed Installation Concepts

It is important to review a few of the concepts relating to a high-availability/<None>distributed install for WebAccess. Distributed installation entails having the WebAccess Application installed on one server and additional WebAccess Agents installed on different servers. It can also mean having multiple WebAccess Applications throughout an organization. In a nutshell, think of this as having options about how to set up a large enterprise WebAccess solution.

Keep in mind that GroupWise gives you the capability to have one entry point via a WebAccess Application that will talk to multiple WebAccess Agents. You can also configure GroupWise domains and post offices to have a preferred WebAccess Agent. This will come into play when you configure which agents will service which users.

Creating a highly available GroupWise WebAccess solution (as explained in this chapter) consists of doing the following:

  • Installing additional GroupWise WebAccess Agents

  • Defining default WebAccess Agents for domains or post offices

  • Defining failover WebAccess Agents that the WebAccess Application can utilize if a preferred WebAccess Agent is not available

The procedure to install additional WebAccess Agents is the same as the one used to install the WebAccess gateway as explained in Chapter 11 in the section "Installing the GroupWise WebAccess Gateway." You need to follow only the part of the section that talks about installing the WebAccess Agent. Although you can install multiple WebAccess Applications, this chapter discusses having only one WebAccess Application and multiple WebAccess Agents. Also, make sure that the encryption key on the newly installed WebAccess Agent matches the encryption key on all the other WebAccess Agents. When you run the GroupWise WebAccess installation, you will generally run just the WebAccess Agent installation and not the WebAccess Application installation.


Configuring GroupWise WebAccess for More Scalability and Stability

For this section, the topic centers on shoring up the WebAccess system and making it more scalable and fault tolerant. With only one WebAccess Application and Agent running, users would be unable to access their mailboxes through WebAccess if either of these components fails. With multiple agents set up and being serviced by multiple applications, the overall WebAccess availability will be greatly enhanced. It also allows you to bring down pieces of the WebAccess system, without interrupting all access to users' mailboxes. This is useful for upgrades, or for maintenance on anything from the GroupWise system to servers to other applications running on the servers. This section begins by discussing what is involved in getting multiple agents and application services working together.

Configuring Multiple Agents and Application Servers for a Fault-Tolerant WebAccess System

With WebAccess, administrators can set up multiple agents and applications that all work together. This section explores how to configure a single application to talk to multiple agents. It also discusses how configuring multiple agents can provide a fault-tolerant WebAccess system. With a simple install of WebAccess, you have only one WebAccess Application talking to a single WebAccess Agent. Very little changes when you consider setting up an application for talking to multiple agents. Consider the following sample scenario that discusses how to make it all work together.

You want to have the WebAccess Application on your Web server communicate with two WebAccess Agents. These agents are installed in close proximity to the two major sections of your WAN. In this scenario, you will see how to configure and set this up.

Before we explain exactly how to configure and set up this scenario, it is very important that you understand how a WebAccess Application determines which agent or agents it should communicate with. When there is more than one WebAccess Agent installed in your GroupWise system, the application must check to see which agent the user should be directed to. Chapter 5, "Working with GroupWise Objects," mentioned that you can configure a default WebAccess object for a domain or post office. Configuring a default WebAccess setting on users' domains or post offices is a key aspect of setting up multiple agents in a GroupWise system. In fact, we recommend that if you have slow WAN links, you install WebAccess Agents in close network proximity to GroupWise post offices. Sure you may need to create a special-purpose domain to house the WebAccess Agent, but that's no problem. One customer has some 30 post offices over slow WAN links. So they created 30 special-purpose domains just to accommodate the WebAccess Agents. Those domains actually reside on the same servers where the post offices are.

Here is the order in which the application will check to determine which WebAccess Agent to log a particular user to:

  1. If there is an agent specified in the URL field that is entered when a request reaches the Web server where the WebAccess Application is running, the Application performs no lookups and sends the user request directly to the agent that was defined in the URL. An example of how to construct the URL to do this follows:

    http://groupwise.wwwidgets.com/gw/webacc?GWAP.ip=137.65.55.211&GWAP.port=7205

    The IP address specified after GWAP.ip= would reflect the IP address of the server where the WebAccess Agent is running, and GWAP.port= is the port the WebAccess Agent is listening on.

  2. Generally the URL to access GroupWise WebAccess does not specify a certain WebAccess Agent. So if no agent is defined in the URL, the application performs a lookup to determine whether a default WebAccess Agent is defined at this user's post office. If so, the user is routed to this agent.

  3. If no default WebAccess Agent is defined at the user's post office, a lookup is performed on the user's domain for a defined default WebAccess object. If one is found here, the user is routed to this agent.

  4. If no default WebAccess Agent is defined at the domain, the application looks in the WEBACC.CFG file for the service provider that it is associated with and routes the user to the first agent defined as a Provider. Here is an example from the WEBACC.CFG file showing the first Provider:

    Provider.GWAP.Default.address.1=137.65.55.211:7205

  5. If no Provider agents are defined, the application reads the COMMGR.CFG file located in the WEBACCESS directory and routes the request to the one agent defined in this file. The method that the WebAccess Application uses to determine which agent to send the user is also a method that the application uses for failover if any agents are down. For example, if there is a default WebAccess Agent defined at the domain level, but it is unavailable, the application then rolls over to the next lookup method, which is the agents defined in WEBACC.CFG, and sends the request to the first agent there. In our case this is Provider.GWAP.Default.address.1=137.65.55.211:7205

If this agent is down, it cycles to the next defined Provider agent in the WEBACC.CFG. In our case it is

Provider.GWAP.Default.address.2=137.65.55.212:7205

If none of the defined Provider agents is accessible, the last resort is to check the agent listed inside the COMMGR.CFG file. If this agent is down, the user cannot log in.

Phew, that is quite a process! The next section breaks this process down into a few scenarios to make sure you understand how the lookup/failover model works.

Lookup/Failover List: Scenario 1

Presume that you have three agents installed in your GroupWise system, all being serviced by one WebAccess Application:

DEFINITION | WEBACCESS AGENT
Entered URL | No agent defined in URL groupwise.wwwidgets.com.
Post office | Agent 1 defined as the default agent for this post office.
Domain | No agent defined.
Agents defined as Providers in the WEBACC.CFG file | Agents 1 and 2. The COMMGR.CFG file has a reference to Agent 3.

With this configuration, when a user logs in, the application builds a list of WebAccess Agents that it uses to send the user's request to. If any of these agents are down, the application cycles to the next agent in the list. The following table shows the list that the application builds regarding which agent this user should be sent/failed over to:

APPLICATION LIST VALUE | GENERATED FROM
Agent 1 | Post office definition
Agent 2 | Service provider list
Agent 3 | COMMGR.CFG file

Because there is an agent defined for the user's post office (Agent 1), this is the first agent that the application tries to access. If this agent is down, it sends the user to the first agent listed in the service provider list (Agent 2). If both of these agents are down, it sends the request to the agent listed in the COMMGR.CFG file.

Note

Technically, two agents are listed as Providers in this example (Agent 1 and Agent 2). Because the Application finds the same Agent twice (Agent 1) from the post office override and as the first Provider, it removes the entry to Agent 1 found as a Provider. The Application does not list or use the same agent multiple times in this situation.

Lookup/Failover List: Scenario 2

Assume that you have four agents installed in your GroupWise system, all being serviced by one application:

DEFINITION | WEBACCESS AGENT
Entered URL | No agent defined in URL webmail.worldwidewidgets.com.
Post office | No default agent defined for the post office.
Domain | Agent 2 is defined as the default agent for this domain.
Agents defined as Providers in the WEBACC.CFG file | Agents 1 and 3. The COMMGR.CFG file has a reference to Agent 4.

Using the preceding table, the following table shows the list that the application builds regarding which agent this user should be sent/failed over to:

APPLICATION LIST VALUE | GENERATED FROM
Agent 2 | Domain agent definition
Agent 1 | Service provider list
Agent 3 | Service provider list
Agent 4 | COMMGR.CFG file

In this scenario, the user does not experience any interruption of service unless all four agents go down. If Agent 2 fails, the application automatically rolls the user over to Agent 1 and so on. With this information, you should carefully plan how you define the agents that the users are directed to. With the understanding you now have, you should be able to design a very reliable WebAccess system.

There's one more little piece that is important. How does the application know whether there is a default WebAccess Agent defined at the domain or post office level? This information is not stored on the Web server, and the application was never designed to directly access a GroupWise domain database to discover this information. Here is what happens.

To build the list of agents when a user logs in, the application must determine whether there is a default WebAccess gateway defined at the domain or post office level for the user. When the user ID and password are entered at the login page for WebAccess, the application sends this information to any one of the agents listed as Providers in the WEBACC.CFG file. The WebAccess Application uses these agents in a round-robin fashion for its initial query. Its initial query to the agent is to look in the domain database for a default WebAccess Agent defined at either the post office or the domain level. The agent answers the query with the results to the application. Now that the application knows whether the user has a default WebAccess Agent defined, it can build the correct list of agents to route the user to.

Now that we have explained the lookup and failover model, the following section explains how to configure this type of setup.

Matching Encryption Keys

For a single WebAccess Application to be able to talk to multiple agents, the encryption key between the application and all agents it communicates with must be the same. The WebAccess Application will read the COMMGR.CFG file located by default in the WEBACCESS directory on the Web server. The COMMGR.CFG file contains the encryption key that must match the encryption key stored in the COMMGR.CFG file located in the DOMAIN\WPGATE\WEBACCESS directory for each of the WebAccess Agents. The easiest way to facilitate seamless communication from the application to each agent is to make the encryption key the same for all agents that a single WebAccess Application will be configured to talk to. (A simple copy-and-paste procedure works great.) You do this by editing the WebAccess Agent that is directly associated with a particular GroupWise domain and accessing the WebAccess settings. Figure 31.1 shows this screen.

Figure 31.1. Editing the WebAccess encryption key

[View full size image]

From here, you should enter the same encryption key on all agents. The best method to use is to take the existing encryption key from your first WebAccess Agent and copy it to the new WebAccess Agent objects in ConsoleOne.

Configuring the Default WebAccess Agents for a Domain or Post Office

To configure a default WebAccess Agent at the domain or post office level, you need to access the properties of the respective domain or post office object. From the respective property pages, choose the GroupWise, Default WebAccess properties page. From here, you click the override box to browse through the eDirectory tree and select the appropriate WebAccess Agent object.

Configuring the WebAccess Application's Provider Agent Failover List

To get the WebAccess Application to recognize the WebAccess Agents it should use for failover, you need to add these Agents as Providers in the WEBACC.CFG file. If you intend to have several WebAccess Agents, it's not necessary to have all of them listed in WEBACC.CFG. We recommend for most customers to have three. The fact that a WebAccess Agent is not listed as a Provider does not mean it will never be used, it just means it will never be used for failover. As you remember from the earlier explanation, a WebAccess Agent is used if it is assigned as the default WebAccess Agent for a domain or post office.

So now you need to access the WEBACC.CFG file. On a NetWare server, the file is generally in SYS:SYSTEM\NOVELL\WEBACCESS.

On our SLES9 server the webacc.cfg file is located in /opt/novell/groupwise/webaccess.

[View full width]
Search the file for Provider.GWAP.Default.address. If there is not a section already, just
   add the providers to the end of the WEBACC.CFG file, in the following manner: Provider
  .GWAP.Default.address.1=137.65.55.211:7205
Provider.GWAP.Default.address.2=137.65.55.212:7205
Provider.GWAP.Default.address.3=137.65.55.213:7205

The syntax is important, so make sure that you make the syntax just as shown.

After the changes are made to the WEBACC.CFG file, you must restart the WebAccess Application for the changes to take effect. On the NetWare 6.5 platform the commands to do this are as shown here:

java killall
java exit
tomcat4

On our SLES9 server these are the commands:

/var/opt/novell/tomcat4/bin/catalina.sh stop
/var/opt/novell/tomcat4/bin/catalina.sh start

Now with the Providers defined, the WebAccess Application will go down the list of Providers if a default WebAccess Agent either is not available or is not defined.


Summary

This chapter explained how to create a highly available WebAccess solution. The method for creating this solution was to create additional WebAccess Agents, and then to make those WebAccess Agents accessible to the WebAccess Application via a failover list.


Chapter 32. Creating a Highly Available GroupWise Internet Agent Solution

Imagine the number of emails going through your GWIA every day, incoming and outgoing. Depending on the size of your organization, this could easily be hundreds of thousands. But even with smaller numbers, consider this: Wouldn't your users be horrified if even a single mail message were "supposedly" lost? So even in smaller environments you will probably be interested to learn about a few techniques to make your Internet SMTP communication more redundant.

This chapter covers high availability of the GWIA from the perspective of what you can do with GroupWise itself; it does not discuss platform-related high-availability techniques such as NetWare, Linux, or Windows clustering, which is at a more OS-related level. Nor does this chapter discuss additional products you could use to strengthen your SMTP stream, between your GWIA and the Internet. We're trying to go to the max with GroupWise itself and we'll see where this brings us.

In this chapter, we propose to disable all the services on your GWIA that you don't really need. Then we dive a lot deeper into the wonderful world of DNS with its A, MX, and PTR records. The logical follow-up is to cover how you can make the incoming SMTP stream more robust, and the next section discusses some new GroupWise 7 options to add mor e redundancy to the outgoing SMTP stream.


The GWIA as a Connector Between SMTP and Other GroupWise Processes

Let's take a closer look at some of the different elements within the GWIA and decide what we need to do to increase the availability of services.

Apart from SMTP, the GroupWise Internet Agent (GWIA) has several subprocesses that can deliver POP3, IMAP4, LDAP, and some other services. But this is not what we're concerned with in this chapter; to be honest, if you take the high availability of your GWIA seriously, you will want to turn off all of these other services, because they will potentially decrease the stability of your GWIA. So our first advice is that if you really need any of these services for your environment, consider creating a specialized GWIA on a separate box. In real life we've seen too many examples of a GWIA abending on a nonessential POP3 thread for a single user, wrecking the availability of SMTP for all. More on how to create a specialized GWIA can be found in Chapter 10, "Installing and Configuring the GroupWise Internet Agent."


DNS Services and GWIA

Now before you do anything to your own GroupWise environment, we need to take a much closer look at the relation between the DNS and your GWIAs.

Understanding Why GWIA Needs to Have Access to a Stable and Fast DNS

When you start your GWIA, the first thing it will do is test the DNS connection. It will actually try to perform a DNS lookup for the domain novell.com and will show the normal GWIA console screen if this attempt succeeds. When troubleshooting problems with the GWIA, we've often found that problems with the DNS were involved.

Tip

If during the startup of the GWIA the blue and almost-blank startup screen stays up for a few seconds or more, you might want to check your DNS. A long pause in GWIA load time is an indication that the GWIA has not succeeded yet to resolve the novell.com DNS query. In most cases after a while this screen will disappear and the normal GWIA console screen will appear, but this is a definite indication of a problematic or slow relationship between your GWIA and the DNS it's trying to access.

A fast and stable DNS service is important, because the GWIA will have to do one or more DNS queries for every email that will be sent. And in some cases the GWIA will even have to do DNS queries when receiving email, for example, when using the option Reject Mail If Sender's Identity Cannot Be Verified, as explained in Chapter 10 and shown in Figure 32.1.

Figure 32.1. The GroupWise Internet Agent configuration Security Settings page showing the option Reject Mail If Sender's Identity Cannot Be Verified

Let's take a look at this subject in more detail. On a high level, when an email is being sent, the conversation goes like this:

  1. Your GWIA gets a new message from the MTA directed to the Internet email address of marcel@clarify.nl.

  2. Your GWIA will strip off the part before the @ sign and will query the DNS for the MX (Mail Exchange) record for the domain clarify.nl with the lowest preference value.

  3. The GWIA should receive an answer from the DNS promptly, and the answer will contain a hostname, like mail.clarify.nl.

  4. Because SMTP sessions can be initiated only with IP addresses, your GWIA will ask for a translation of the name mail.clarify.nl to an IP number, effectively asking for a DNS A record.

  5. The GWIA will then initiate an SMTP or even an ESMTP session (more about this in Chapter 10) with the SMTP server for clarify.nl on the other side, which is supposed to be listening on the IP address that resolves to mail.clarify.nl.

  6. Let's assume that the receiving SMTP server has enabled an option like Reject Mail If Sender's Identity Cannot Be Verified. Before this SMTP server can accept the SMTP session, it will record the IP number of your GWIA and will check this number and the hostname against the DNS, using a reverse address lookup to translate the IP number into a hostname. The record that will be checked is the so-called PTR or reverse address lookup record. In this example, if the IP number matches the hostname mail.clarify.nl, the session will be accepted; otherwise, it will be rejected.

  7. From this moment on, the normal SMTP data transfer will start, and in the end the message will be transferred if all other criteria like a valid email address and message size are met.

Note

It's essential that you understand the significance of step 6. Your GWIA will be able to communicate with all other SMTP servers only if your A records, MX records, and PTR records are configured properly. In real life we quite often see that the A and MX records are configured properly (otherwise nothing would work), but in too many cases the PTR records are not configured properly. This will be a problem only when sending mail to some Internet domains that are using an option like Reject Mail If Sender's Identity Cannot Be Verified, but of course for this high-availability solution we want this to be configured properly.

This situation is of course a bit more complicated when you have more than one GWIA for your GroupWise system, as is discussed later in this chapter. Make sure that your hostname as shown to the outside world matches the DNS; for example, if on NetWare your HOSTNAME file in the SYS:\ETC directory contains an internal name like NW-FS01.clarify.nl, you might need to change the hostname. You will have to edit both the HOSTNAME file and the HOSTS file in the SYS:ETC directory to reflect the external name mail.clarify.nl. When changing this, make sure that certificate files used by this server also contain the same hostname.

Because you cannot configure your GWIA to use its own DNS servers, your GWIA relies on the proper configuration of the DNS services of the underlying operating system. You might want to check out the speed of several DNS servers; it might be surprising to know that in some situations the DNS service of your own provider is not the best (fastest) solution. If that's the case, you should consider configuring the DNS to go to a faster third-party DNS server. On NetWare you can do this in Inetcfg, Protocols, TCP/IP, DNS Resolver Configuration. In Windows and Linux there are similar tools.

Note

There is nothing wrong with having your GWIA point to an internal DNS server, which will actually try to offer answers from its own internal cache and will forward all new requests to some outside DNS server. This can indeed be faster than having to consult an external DNS server for every SMTP session. However, there is one caveat: Your own DNS server might cache this data for quite some time, and this could mean your GWIA will use stale information much longer than when connected directly to the external source. The problem is that if somebody makes changes to their DNS records, it will already take some time before these changes are propagated through the Internet, and with your own DNS server you've just added some extra latency to this process.

This section explained why you need to spend some time looking at the configuration of your DNS lookups on your GWIA servers, because this is essential for a highly available GWIA.

How Multiple MX Records Could Help You Create a Highly Available SMTP Service

Now let's consider what happens when somebody on the outside wants to send you a message via SMTP. As mentioned in the preceding section, the other person's SMTP server will ask for your MX record with the lowest preference number and, based on that information, will try to set up an IP connection with your SMTP server. Alas, for whatever reason, your GWIA is not running. The sending SMTP server will detect this unavailability. Then the SMTP server will query the DNS again to see whether there are any other MX record entries with the next higher preference number. If so, this server will try to set up a connection to this second SMTP server as well. If this also fails, most SMTP servers will query for the next MX record until it can set up an SMTP connection.

So this mechanism gives you a lot of flexibility to set up your own incoming SMTP redundancy, especially if you combine this with a service that most ISP (Internet service providers) can offer, often called batch-SMTP or queued-SMTP. The idea behind batch-SMTP is that if your own SMTP servers are not available, your ISP will act as a fallback SMTP server for your domain. The SMTP server of the ISP will then accept all SMTP sessions for your domain and will queue all messages for you.

Note

There is one important aspect you need to understand: Your ISP's SMTP server has no clue what email addresses or message sizes are acceptable and therefore will have to accept all messages for you, even if it's spam that would normally be rejected by your own system. In the good old days of dial-up, batch-SMTP was quite common and even necessary, but nowadays this could lead to a rather large queue at the ISP. Therefore, certain ISPs are not so fond of this option anymore and don't offer this type of service unless you ask for it.

As soon as your own SMTP servers are back online, your ISP will detect their presence. The ISP will forward all the messages in the batch-queue to be handled by your own SMTP servers and will flush the queue.

A More Detailed View of the DNS Records You Need for a Highly Available SMTP Service

So let's take a look at what do you need to do to enable multiple incoming GWIAs and batch-SMTP. Let's start with batch-SMTP first. You will need to talk to your ISP and ask them to set up this additional service for you. Make sure you understand how they're going to create this setup. It's especially important that you understand how they will detect whether your SMTP servers are back online again: Will they test that every few minutes? Will they ping the IP address of your SMTP server or the DNS name? Or are they trying to set up an SMTP session with your servers to detect your presence?

After you've agreed on those details, your DNS will need to be reconfigured for the three record types, each of which are discussed in the sections that follow.

MX Records

You will need an MX record for every server that will accept email for your system, for example as shown in Table 32.1.

Table 32.1. The Typical Answer for an MX Query on an Internet Domain, in This Case for clarify.nl

DOMAIN

TYPE

CLASS

TTL

ANSWER

clarify.nl.

MX

IN

120

mail.clarify.nl. [Preference = 100]

clarify.nl.

MX

IN

120

mail2.clarify.nl. [Preference = 105]

clarify.nl.

MX

IN

120

mx.wirehub.net. [Preference = 120]

The order of the MX records is important. In this case the first server that will be contacted for an SMTP session with clarify.nl is mail.clarify.nl, because it has the lowest preference number or preference value, 100. In this example you see that the second SMTP server to be contacted is mail2.clarify.nl with preference 105, and if both SMTP servers are unavailable the SMTP server mx.wirehub.net from the ISP will be used with preference 120.

Tip

There are several good tools that allow you to do DNS queries, but one of our favorites is online at www.dnsstuff.com. The tools of this site are available with a simple browser from almost anywhere. At the upper-right corner of this web page, you can go to the section DNS Lookup, select MX from the pull-down menu, and type in the domain name, and voilà!, there are the results as presented in these examples.

A more typical example of the usage of MX records comes from how Novell has its MX records defined. At Novell all three SMTP servers have the same preference value of 5, as shown in Table 32.2. This means that if any SMTP server tries to set up a connection to novell.com, any one of these three servers will be used at random.

Table 32.2. A More Atypical Answer for an MX Query on the Internet Domain novell.com

DOMAIN

TYPE

CLASS

TTL

ANSWER

novell.com

MX

IN

21600

minotaur.novell.com. [Preference = 5]

novell.com

MX

IN

21600

prv-mx.provo.novell.com. [Preference = 5]

novell.com

MX

IN

21600

prv1-mx.provo.novell.com. [Preference = 5]

A Records

Now that you have taken a look at the MX records, we need to define the proper A record as the hostname for every server that will accept email for your system, for example as shown in Table 32.3. What's a little surprising but not unusual is that the ISP has more than one IP address connected to the same hostname mx.wirehub.net.

Table 32.3. The Typical Answer for an A Record Query on Several Hostnames, in This Case for mail.clarify.nl, mail2.clarify.nl, and mx.wirehub.net

DOMAIN

TYPE

CLASS

TTL

ANSWER

mail.clarify.nl.

A

IN

120

195.86.245.69

mail2.clarify.nl.

A

IN

120

195.86.245.71

mx.wirehub.net.

A

IN

300

194.165.92.55

mx.wirehub.net.

A

IN

300

194.165.92.56

mx.wirehub.net.

A

IN

300

194.165.92.57

mx.wirehub.net.

A

IN

300

194.165.92.58

mx.wirehub.net.

A

IN

300

194.165.92.59

mx.wirehub.net.

A

IN

300

194.165.92.60

The A records from Novell show a more typical example, without batch-SMTP; all three SMTP servers are internal servers, as shown in Table 32.4.

Table 32.4. The More Typical Answer for an A Record Query on Several Hostnames for novell.com

DOMAIN

TYPE

CLASS

TTL

ANSWER

minotaur.novell.com.

A

IN

21600

130.57.21.1

prv-mx.provo.novell.com.

A

IN

43200

130.57.1.10

prv1-mx.provo.novell.com.

A

IN

43200

130.57.1.11

PTR Records

In most cases sending and receiving email will work with just a few MX records and A records, but as explained before you definitely need to look at your reverse address lookup or PTR records as well, as shown in Table 32.5. This table shows the result data for the lookup for mail.clarify.nl from www.dnsstuff.com, including the details to explain how the result came to be.

Table 32.5. The Typical Answer for an A Record Query on Several Hostnames, in This Case for mail.clarify.nl, mail2.clarify.nl, and mx.wirehub.net

PREPARATION:

The reverse DNS entry for an IP is found by reversing the IP, adding it to in-addr.arpa, and looking up the PTR record. So the reverse DNS entry for 195.86.245.69 is found by looking up the PTR record for 69.245.86.195.in-addr.arpa.

All DNS requests start by asking the root servers, and they let you know what to do next.

HOW I AM SEARCHING:

Asking i.root-servers.net for 69.245.86.195.in-addr.arpa PTR record:i.root-servers.net says to go to tinnie.arin.net. (zone: 195.in-addr.arpa.)

Asking tinnie.arin.net. for 69.245.86.195.in-addr.arpa PTR record:tinnie.arin.net [69.25.34.195] says to go to ns2.wirehub.net.(zone: 86.195.in-addr.arpa.)

Asking ns2.wirehub.net. for 69.245.86.195.in-addr.arpa PTR record:Reports mail.clarify.nl. [from 194.165.94.5]

ANSWER:

195.86.245.69

PTR record: [A=195.86.245.69]

mail.clarify.nl.

[TTL 86400s]

Now let's assume that something is wrong with one of the PTR records for Novell. If you look at the data given earlier in Table 32.2, the three servers that are accepting mail for novell.com all have the same preference. If an external SMTP server tries to connect with novell.com, the server will be assigned at random. Now take a look at the SMTP configuration in Table 32.6 and compare this to Table 32.2 and Table 32.4. There is a problem in this configurationcan you identify it?

Table 32.6. The More Typical Answer for an A Record Query on a Several Hostnames for novell.com

LOCATION:

United States [City: Provo, Utah]

PREPARATION:

The reverse DNS entry for an IP is found by reversing the IP, adding it to in-addr.arpa, and looking up the PTR record. So the reverse DNS entry for 130.57.21.1 is found by looking up the PTR record for 1.21.57.130.in-addr.arpa.

All DNS requests start by asking the root servers, and they let you know what to do next.

HOW I AM SEARCHING:

Asking e.root-servers.net for 1.21.57.130.in-addr.arpa PTR record:e.root-servers.net says to go to indigo.arin.net. (zone: 130.in-addr.arpa.)

Asking indigo.arin.net. for 1.21.57.130.in-addr.arpa PTR record:indigo.arin.net [192.31.80.32] says to go to ns.novell.com.(zone: 57.130.in-addr.arpa.)

Asking ns.novell.com. for 1.21.57.130.in-addr.arpa PTR record: Reports IST_21_1.sjf.Novell.COM. [from 137.65.1.1]

ANSWER:

130.57.21.1

PTR record: [A=130.57.21.1]

IST_21_1.sjf.Novell.COM.

[TTL 3600s]

130.57.1.10

PTR record: [A=130.57.1.10]

prv-mx.provo.novell.com.

[TTL 86400s]

130.57.1.11

PTR record: [A=130.57.1.11]

prv1-mx.provo.novell.com.

[TTL 86400s]

Note

For readability, the first few lines about "Preparation" and "How am I searching" are not repeated; the "Answer" section contains the relevant data.

The problem is of course the IP number 130.57.21.1 pointing back to IST_21_1.sjf.Novell.Com instead of pointing back to minotaur.novell.com. As you can suspect from the name IST_21_1.sjf, this is an internal server name that should not be used on the outside. And the problem is this: If the SMTP server that receives mail from novell.com has enabled the Reject Mail If Sender's Identity Cannot Be Verified option of the GWIA, not every session from novell.com would be accepted. Depending on the configuration, on average every one out of three sessions could be problematic. Of course, this example is not real; it is just a simulation of what could go wrong.

Warning

Always make sure that all your MX records have properly configured PTR records. If not, some external SMTP environments might not be able to process your mail properly.

And although we like to advise you to enable the option Reject Mail If Sender's Identity Cannot Be Verified on the GWIA, the sad reality is that so many external SMTP servers are not configured properly that you might miss too many emails and your users would start complaining. They will mention that the other side has called them and that for whatever reasons your mail environment did not accept their "valid" mail. Even if you argue that this happens because of a misconfiguration at the other side, you will probably not win this battle.


Using Multiple GWIAs to Strengthen the SMTP Stream for Incoming Messages

You just need to make sure that the DNS is configured properly, and then you can install an additional GWIA.

First of all some prerequisites: You will need a public IP number per additional GWIA, or otherwise you will not be able to create the necessary MX, A, and PTR records. For this example we assume that your first public IP number is 137.65.55.211 and your organization can use a whole range of 16 public IP addresses, so you can use the next few numbers as well.

You will also need an extra box on which you can add a secondary domain with MTA and the additional GWIA. This could be either an existing server or a new server, as long as this server does not have any other SMTP processes talking on port 25 and can connect to the Internet with one of your public IP numbers. And yes, you do need a secondary domain, as explained in Chapter 10. We prefer to have a secondary domain database on the server where the GWIA is running, because the GWIA can then have access to a copy of the domain on the local hard disk.

After reading the preceding section, you should find it pretty easy to understand what you need to do. Let's take a closer look:

  1. First you need to determine what your existing DNS entries are. Let's take a look at www.dnsstuff.com and assume that your current DNS configuration looks as shown in Table 32.7.

    Table 32.7. The Existing DNS Entries as Defined for wwwidgets.com

    DOMAIN

    TYPE

    CLASS

    TTL

    ANSWER

    wwwidgets.com

    MX

    IN

    21600

    smtp.wwwidgets.com. [Preference = 50]

    smtp.wwwidgets.com.

    A

    IN

    21600

    137.65.55.211

    137.65.55.211

    PTR

    smtp. wwwidgets.com.

    [TTL 3600s] [A=137.65.55.211]

  2. We want to add a second GWIA. For more clarity in this book, we will use a distinct name; instead of something like smtp2.wwwidgets.com we will call this server mx2.wwwidgets.com. This server will use IP number 137.65.55.212 and this secondary GWIA will be a fallback GWIA only; so we will use the preference 75. That way an external SMTP server will first try to reach our primary GWIA smtp.wwwidgets.com. So the ISP needs to create a few new records, and an email to the ISP could read like this:

    Dear ISP,

    Can you please create a few additional DNS records for our domain? We need the following three entries:

    A record: mx2.wwwidgets.com -> 137.65.55.212

    MX record for wwwidgets.com: mx2.wwwidgets.com with preference 75

    PTR or reverse address lookup record: 137.65.55.212 -> mx2.wwwidgets.com.

    Please do not forget to add the PTR record as well and inform us when ready. Thanks!

    Regards from your patient customer.

    Tip

    Make sure you do finish this task some days before you want to create your secondary GWIA, and also be sure to check the results. Quite often the MX and A record will be no problem, but for many reasons the PTR records can be difficult for some ISPs.

    There will be no problems if these records have been created before your secondary GWIA is "on the air," because the preference value for this GWIA is higher and the outside world will first try to contact your primary GWIA.

  3. While you're waiting for the ISP to finish the task of creating those DNS records, you can prepare the new or existing server. After installation and configuration of the basic server, you need to configure this server to use the public IP number, in this example 137.65.55.212, and you need to make sure that the hostname is the same as the A record, in this example mx2.wwwidgets.com.

  4. The next step is to create a secondary domain as described in Chapter 10, "Installing and Configuring the GroupWise Internet Agent," and Chapter 19, "Building Your GroupWise System Correctly." You need to install the MTA on this server and the GWIA as well, as described in these same chapters. During the installation of the GWIA you need to make particularly sure that the correct hostname mx2.wwwidgets.com is specified and not smtp.wwwidgets.com.

  5. All you need to do now is configure this new GWIA according to the recommendations from Chapter 10, and then you're ready to go. You can test the new GWIA by using telnet to connect to port 25 on mx2.wwwidgets.com, and you should see a cheerful OK coming back.

That's indeed all you need to do. As soon as your primary GWIA is somehow not available, for example due to maintenance, your secondary GWIA will accept SMTP sessions and will forward all incoming messages to your GroupWise system.

Warning

Although this is all very nice and true for your incoming mail, a secondary GWIA will not automatically start handling all outgoing mail as well. Your GroupWise system will still try to send all mail via the primary GWIA. Before GroupWise 7, the only solution was to make some manual changes to make sure that all mail was going to be routed via the secondary GWIA. Some new additions to GroupWise 7 will give you automatic failover and thus redundancy on the outgoing SMTP stream as well, as explained in the next section.


Using Multiple GWIAs for a Redundant SMTP Stream for Outgoing Messages

As mentioned in the preceding section, before GroupWise 7 your GroupWise system had no way to automatically redirect the outgoing SMTP messages from one GWIA to another when the primary GWIA was unavailable. And the reason was pretty simple: The MTA that was forwarding these messages to the GWIA simply dropped the messages in a directory to be picked up by the GWIA and could therefore not easily see that a GWIA was not functioning anymore. This could also mean that on your MTA console screen all gateways seemed to be in an "open" state, though one of them was actually down.

But that has all changed with GroupWise 7. The MTA can now communicate with the GWIA over IP via MTP (message transfer protocol), much like the MTA and the POA already use. And as soon as the MTA detects that the GWIA is not available, it can redirect the outgoing SMTP message stream to an auxiliary GWIA, if created and so defined. This great new functionality is a welcome addition to the preceding section and really finishes everything off. Let's take a closer look at this.

First we assume that you've already created an additional domain on a separate server. You also have installed the MTA and GWIA software on this box and have configured all the necessary details, as described in Chapter 10 and the preceding section in this chapter. For this example, we assume that the internal server name is WWWFS2, the external hostname is mx2.wwwidgets.com with IP number 137.65.55.212, and all the necessary DNS entries as described in the previous sections have been created. If not, there is no use to read on; you need the additional domain properly configured to be able to use this successfully, so be sure to take a look at these earlier sections first.

The next step you need to take is to make sure that all of your GWIAs communicate with their MTAs via TCP/IP using MTP (message transfer protocol). This is very important, because this is the only way a MTA can properly detect whether a GWIA is running. If you use the older direct access mode, in which the MTA writes files to a subdirectory to be read by the GWIA or vice versa, there is no way the MTA can see whether the GWIA is still running properly.

Checking to Make Sure That MTA and GWIA are Using MTP

We assume that you've upgraded all of your GroupWise domains, post offices, and the corresponding agents and gateways to GroupWise 7. If not, at least the domains where your GWIAs reside need to be on GroupWise 7. You can easily check this:

  • In ConsoleOne, go to your domain object and open the properties. On the first page called Identification, you should check the property called Database Version, which should read 7. Be sure to check that this is indeed GroupWise 7 for all domains that contain GWIAs.

  • The next thing you should check is whether the GWIA is indeed configured with the correct properties and whether the MTP port called Message Transfer is configured correctly. In ConsoleOne, open the properties of your GWIA and go to GroupWise, Network Address, as shown in Figure 32.2. In most cases the value for this port will be something like 7102, but it can be any free port. Be sure to check this for all of your GWIAs.

    Figure 32.2. In ConsoleOne, this GWIA is showing a properly configured MTP port; in this case Message Transfer will be via port 7102

    [View full size image]

Note

In some cases we've noticed that ConsoleOne does not show the correct property screen for the network address of your GWIA, even if you upgraded the GroupWise 7 GWIA code. In most cases this has been the case with GWIAs that have been upgraded from previous versions. In the domain database and thus in ConsoleOne, for whatever reason, the version of the GWIA is still on version 6 or 6.5. All you need to do is to make sure that the GWIA is indeed using GroupWise 7 code and then change the version in ConsoleOne to version 7. After you close the GWIA object and reopen it, you should be able to see the correct version as version 7.

  • You need to check only one more thing: Does your MTA indeed communicate with the GWIA via IP? If your GWIA is not running, you can now easily see this on the console screen of your MTA, because your GroupWise 7 MTA will be able to detect that the connection to the GWIA is open or closed and will show that on the main screen. In Figure 32.3 the GWIA was not active and the MTA has marked the connection to one of its gateways as closed. This is a new feature of GroupWise 7.

    Figure 32.3. The MTA has not been able to open the connection to the GWIA, as can be seen in the upper-left corner, in the Gateways section

    [View full size image]

In Figure 32.4 you can se e the details for the closed GWIA, including the Hold directory. In the old days, all the MTA could do was drop all outgoing message files temporarily in this holding directory, but when you finish the tasks in this section, the GroupWise 7 MTA should be able to find an alternative outbound route to the Internet.

Figure 32.4. The MTA showing the details of a closed connection to the GWIA, including the Hold directory where all delayed message files will be stored if no alternative GWIA is configured

[View full size image]

Configuring Your Domain to Use an Alternative GWIA

Now that you've checked all the prerequisites in the preceding section, you can enable the option to use an alternative GWIA with the following steps:

1.
In ConsoleOne, go to the properties of the domain object that owns the primary outbound GWIA.

2.
Go to the Internet Addressing page; at the bottom you will find a property called Alternate Internet Agent for Outbound SMTP/Mime Messages.

3.
From the drop-down list, select the alternative outbound GWIA, as shown in Figure 32.5. Confirm your choice by clicking OK.

Figure 32.5. Configuring your domain object to use an alternative GWIA if your primary GWIA is not running

[View full size image]

And that's all. You can easily test your setup by bringing your primary outbound GWIA down, after which all outgoing messages should be transferred via the alternative outbound GWIA.

Note

A few remarks:

First of all, note that you can (currently) specify only one alternative GWIA. If this GWIA is also not available, your MTA will have to store all messages in the Hold queues.

Second, your MTA will communicate to the alternative GWIA via IP, so make sure that the MTA from your domain is indeed allowed to communicate with this GWIA. Check the firewall and correct the settings if necessary.

Third, the MTA will not transfer any already stored and older messages from a Hold directory to the alternative GWIA. If for whatever reason there are messages in the Hold directory for the primary GWIA, these will be processed only if your primary GWIA comes back online (or you should manually move them to the correct location).


Summary

This chapter has shown the many ways you can take the already-high availability of your GroupWise Internet Agent to an even higher level, discussing the role of the DNS services in depth and exploring the new alternative GWIA option. This knowledge can be an excellent basis for delivering even better SMTP services in your own environment.


Chapter 33. Creating Solutions to Limit Post Office Message Store Size

One of the biggest challenges of an administrator of an Integrated Collaboration Environment (ICE) such as GroupWise is retention management. Many people use their GroupWise mailbox intensively; some of them more or less live in GroupWise. These users want to save everythingevery email, every calendar appointment, in some case from as long as 10 years ago. And more and more mail is coming in, so here's the challenge: How are we going to store all of this on our GroupWise server?

The good news is that from a theoretical point, there is no practical limit to the size of a mailbox or a post office. In fact, Erno has been working these past few years with a caching mailbox that has grown to 9.5GB as of the writing of this book. Still GroupWise does not complain! Erno's laptop sometimes does, though, because of lack of disk space. Now take a look at your environment, count the number of users, and multiply that with, let's say, 10GB. An amazing number, isn't it?

You may want to consider techniques to limit the size of your post office; otherwise, the amount of data you have could become unwieldy and difficult to back up. This chapter explains how to enable mailbox size limits, how to limit the size of attachments, and how to save precious post office space by using third-party archiving solutions. One warning: Whenever you start using any of these techniques, make sure that what you're doing is legal. Some organizations might not be allowed to delete any item from GroupWise because of the rules and regulations that apply. For example, HIPAA and Sarbanes-Oxley have specific ideas on what you can and can't do with your emails, so be sure to check which rules and regulations apply to your organization.


Mailbox and Message Size Limits

GroupWise has had an option to limit mailbox sizes since version 6.0, but over the years many improvements and enhancements have been made to the original concept. GroupWise 7 not only limits the size of the online mailbox, but also can manage the size of the offline caching or remote mailbox. Furthermore, administrators can now configure GroupWise so that they receive notifications when a user's mailbox size is exceeded, as shown in Figure 33.1.

Figure 33.1. New mailbox size features in GroupWise 7: the option to limit the size of the caching mailbox as well as to send notifications to the administrator

[View full size image]

In the old days, a user with a caching mailbox would never be bothered with the limitations of his online mailbox, because the caching client software would not know about those limitations and would look only at the space of the local hard disk of the laptop or desktop. If the online mailbox of a user would hit the limit, but the user was only using caching mode, in some cases the user might not even be aware of the restrictions of his online mailbox. However, messages would not be sent anymore because the limit was exceeded. That's all over now with GroupWise 7, because you can apply the same limits to the caching or remote mailbox as well.

Note

Be careful when applying this feature to existing caching mailboxes. If you do set a limit, this algorithm will do exactly what you want: It will limit the size of the caching mailbox. Depending on what other options you've selected, this could mean that this limit will now indeed be applied to this mailbox. If a user already has a caching mailbox over the limit she might be forced to start cleaning before anything else can be done. Our advice is to make sure you know the size of your mailboxes, not only in online mode but also in caching mode. And don't be surprised if in some cases the caching mailbox is larger than the online mailbox.

Also note that applying mailbox size limits to caching or remote mailboxes will work only when the GroupWise 7 client is used. The GroupWise 6.5 client has no clue how to handle this.

An Overview on How to Enable Mailbox and Message Size Limits

Let's take a high-level overview of the mechanism to manage the mailbox size first, before diving into the details. To enable this, we must take the following steps:

1. | Investigate the current mailbox size to determine the right mailbox size limits.
2. | Communicate with the users about the new policy and the consequences.
3. | In ConsoleOne, configure the client options for a domain, post office, or user.
4. | When first used, run a GWCheck job to make sure that the settings are correctly pushed into the user database.
5. | Monitor the proceedings and apply changes when necessary.

So let's take a closer look at these steps.

Note

Be aware that currently the mailbox size restrictions will be shown in the Windows client and in WebAccess, but not yet in the cross-platform client on Linux and MAC.

Determining Current Mailbox Sizes

We can use standard GroupWise tools to determine the mailbox size. Just run GWCheck and gather the statistics, from which we can determine the current mailbox sizes, as illustrated in these steps:

1.
In ConsoleOne, select either a post office or one or more users, and select the menu option Tools, GroupWise Utilities, Mailbox/Library Maintenance (right-clicking won't work if you've selected multiple users).

Tip

If you select one or more users, you will get a result file per user; if you select a complete post office, you will get the details of all users in a single result file. In most cases, depending on your needs, you might want to select a post office to get one (large) file with all results, instead of receiving potentially hundreds of separate result files.

2.
Select the action Analyze/Fix Databases and be sure to enable only Contents and Collect Statistics. On the Databases tab, at the bottom, enable User and Message. On the Results tab, make sure that the administrator gets a copy; you could also send a copy directly to your own mailbox. Some of these options are shown in Figure 33.2.

Figure 33.2. Options to collect information about the current mailbox sizes using GWCheck

[View full size image]

Note

You can also use the standalone Win32 GWCheck utility with the same parameters, but as discussed in earlier chapters, for speed and other reasons we prefer to run the GWCheck on the POA.

3.
Open one of the mailboxes where the log file have been sent, and take a look at the results. You should see something like what is shown in Figure 33.3.

Figure 33.3. The details of one user in the GWCheck log-file: the mailbox of this user is 55134KB; there are no mailbox size limits yet

[View full size image]

As the example in Figure 33.3 shows, by using the GWCheck log files you can eventually find all the necessary details to create a proper report, on which you can base your recommendations for the new mailbox size limits. However, we would like to point out some very useful tools:

  • GWAVA has a product called Redline that can generate reports like this automatically in a much more readable format. Redline offers much more; check it out at www.gwava.com.

  • IntelliReach offers MessageInsight, capable of generating numerous reports about your GroupWise system. You can find more info at www.intellireach.com.

  • If you're just interested in a more comprehensive report about mailbox sizes, you might like to take a look at GWMBSize, a free tool that just creates mailbox size reports. You can find GWMBSize on Novell Cool Solutions at www.novell.com/coolsolutions/tools/14034.html.

We very much like the more advanced tools such as GWAVA and IntelliReach, but in this case as a first step we've used the much simpler GWMBSize tool to make our GWCheck log files more readable. Part of the result is shown in Figure 33.4.

Figure 33.4. GWMBSize offers a much more drilled-down report about mailbox sizes than the normal GWCheck log can offer

[View full size image]

As you can see in this example, the largest mailbox is 574MB and the average mailbox size is 94MB. The difficulty is, of course, to determine the necessary mailbox size restrictions. Either you can create a very liberal mailbox size restriction for everyone, in this case, for example, 750MB, or you can create several levels, for example, "normal" users would be able to store 250MB and IT users would be able to store 750MB. In conjunction with the mailbox size, you might also want to set a maximum message size, making sure that users won't be able to use your GroupWise system to send all these nice music files or movies to their friends.

Let's assume that this organization has enough disk space to allow every user to use 500MB for their mailbox and the warning lights will start blinking if a user reaches the 75% limit. In our example we will also implement a 1MB maximum message size.

Communicating with Your Users About Mailbox and Message Size Limits

Before you can enable mailbox size limits, you must certainly inform your users about the consequences. Also, you may want to consider phasing in the mailbox size limits in two parts. For example, in the first phase you could set the mailbox size limit to the maximum mailbox size limit of 4,000MB (4GB). Most of your users will not exceed this maximum, but all users will get the Mailbox Size tool enabled in their GroupWise client. Then the users get a chance to get more familiar with the tool, before ever having to use it to get in compliance with your mailbox size policy. Then in the second phase, when you have actually set the mailbox size limit, you should make the users aware that they now might see a first warning if they exceed the limit you've configured, in our case 75%, as shown in Figure 33.5. The GroupWise WebAccess client will also indicate to a user the percentage of the allocated disk space that they have taken, as shown in Figure 33.6.

Figure 33.5. The GroupWise Win32 client will warn the user when the threshold for the mailbox size limit is exceeded. Also notice the Mailbox Size indicator at the bottom of the client

[View full size image]

Figure 33.6. The GroupWise WebAccess client will warn the user when the threshold for the mailbox size limit is exceeded. There is a Mailbox Usage indicator in the upper-right corner

[View full size image]

In the GroupWise Win32 client the user will have the option to use the mailbox cleanup tool, as shown in Figure 33.7.

Figure 33.7. The mailbox cleanup tool in the GroupWise Win32 client

[View full size image]

Of course, a user can choose to ignore all these warnings, but as soon as the mailbox size limit is exceeded, at the next login the user will be forced to clean up, as shown in Figure 33.8.

Figure 33.8. The user is forced to use the mailbox cleanup tool when the mailbox size limit is exceeded

[View full size image]

Because you will also implement message size restrictions, you will want to inform your users about what they will see if they try to send a message that exceeds the limit, as shown in Figure 33.9.

Figure 33.9. This user is trying to share a new 8.36MB version of Acrobat with a co-worker via email; of course, he should not be surprised to get this warning

Now that you've communicated about all of these limitations, you're ready to start the implementation of these restrictions.

Implementing the Mailbox and Message Size Limits

After you've determined the mailbox and message size restrictions and you've informed your users about the new policy, you can start with the implementation, which is actually pretty simple. Let's take a closer look at the steps:

1.
In ConsoleOne, select either a post office or one or more users, and select the menu option Tools, GroupWise Utilities, Client Options (right-clicking won't work if you've selected multiple users).

2.
In the Client Options screen, click on Send and go to the tab called Disk Space Mgmt, as shown earlier in Figure 33.1. Select the options as discussed previously, including the options to send notifications to the administrator for both events.

Tip

Be sure to check whether the administrator option on all of your domain objects is indeed configured as needed. In too many cases, we've seen that this was not properly filled or all the admin messages were sent to a mailbox that nobody ever bothered to look into. Especially in this case, consider creating rules to forward messages with certain subjects to other (departmental) administrators.

3.
After enabling mailbox and message size restrictions for the first time, you probably will get a warning like the one shown in Figure 33.10, which encourages you to run a Mailbox/Library Maintenance. This is indeed necessary to push the right fields and values into the user databases, so be sure to run this as suggested.

Figure 33.10. After enabling mailbox or message size restrictions for the first time, you likely will get this warning message

[View full size image]

Note

In our testing we found that the GroupWise Administrator software takes a little while to launch the Mailbox/Library Maintenance screen. Don't worry; it will come up eventually, based on our testing.

4.
If you click Yes, this version of the ConsoleOne snap-ins will immediately direct you to GWCheck with the correct options, as shown in Figure 33.11.

Figure 33.11. The GWCheck screen will be automatically launched with the correct options

[View full size image]

And that's it. When your users restart their client, they should be able to see the mailbox size indicator at the bottom of the Win32 client or in the upper-right corner of WebAccess. And whenever they try to send a message that is larger than allowed, they will get a warning like that shown in Figure 33.9.

Monitoring Mailbox and Message Size Limits

If in the previous steps you indeed have enabled the options to be notified if somebody exceeds the threshold or mailbox size restrictions, you can respond as soon as possible. But even better than being reactive, you should be proactive by using the techniques mentioned in earlier sections. Just run your GWCheck regularly and use GWMBSize or one of the other tools mentioned. An example of a GWMBSize report that shows the mailbox size thresholds is shown in Figure 33.12.

Figure 33.12. A simple report showing that the first two users have exceeded their mailbox size limit or threshold

[View full size image]


Forcing Message Size Limits on the Internet Agent

There are several ways in which we can limit message size within GroupWise; you've seen such a method in the previous sections, and this option also applies to internal messages. There has always been another option as well: You can apply limitations on the incoming and outgoing SMTP messages via the Internet Agent (GWIA). This method will have no effect on internal messages, but it can be used to apply very granular restrictions on incoming and other restrictions on outgoing messages.

And the good news is this: Because the GWIA is an Enhanced SMTP (ESMTP) server, it will even negotiate about these message size restrictions with any other ESMTP server during the ESMTP handshake before sending or receiving messages that are too large, thereby saving valuable bandwidth. That's all the more reason to take a closer look at message size limits. We'll look next at the steps to configure message size limits.

Assume that you want to limit the message size for most of your users to 1MB for incoming SMTP and 2MB for outgoing SMTP. But you don't want to apply these restrictions to everyone, so let's assume that you've created a GroupWise distribution list called IT-admins. Let's take a look at what we need to do to implement this policy:

  1. In ConsoleOne, go to your GWIA object, open the properties, and go to the tab called Access Control,as shown in Figure 33.13.

    Figure 33.13. The Access Control properties of the GWIA

    [View full size image]

    If you did not configure access control on the GWIA before, you should see something similar to what is shown in Figure 33.13, a single entry called Default Class of Service in the top box and a second entry, Everyone, in the bottom box.

    Note

    All settings created here will be stored in a small database called GWAC.DB, which you can read more about in Chapter 10.

  2. Select the Default Class of Service and click on Edit. You will have the option to enable message restrictions for everyone, both for incoming messages and for outgoing, as shown in Figure 33.14. After entering the desired values, click OK once to return to the Access Control screen.

    Figure 33.14. On the GWIA, all incoming messages for Everyone are restricted to 1MB

    [View full size image]

  3. In the Access Control screen, click on Create to create a new class of service. Give this new this class of service a logical name, like IT-admin-service.

  4. On both the SMTP Incoming screen and the SMTP Outgoing screen, select the option Allow Incoming Messages and deselect the message size box. Click OK once.

  5. In the next screen, activate the distribution option in the lower-right corner and select the IT-admins distribution list. Click OK to go back to the Access Control screen. Your screen should look as shown in Figure 33.15, where the IT-admin-service is linked to the IT-admins distribution list.

    Figure 33.15. The IT-admin-service is linked to the IT-admins distribution list

    [View full size image]

  6. Either click Apply or close the GWIA object and reopen it again to be able to test the new class of service.

  7. To test which restrictions apply to which user, on the Access Control page click on the Test button in the lower-left corner. Select any user you would like to test and click on the View Access button in the lower-right corner to see which restrictions apply.

  8. If you click on any restriction line, you will see where the restrictions are coming from, as shown in Figure 33.16.

    Figure 33.16. You can easily see where a restriction comes from by clicking on the line; at the bottom part of the screen, the Class of Service, Domain, Post Office, and Member ID are shown

    [View full size image]

And that's it: You've now implemented message restrictions on the incoming and outgoing GWIA messages. You can easily test this with an external account, although the message that will come back from this external system if a message is too large can vary greatly.


Exploring Archiving Solutions

All of this talk of mailbox restrictions is very nice, but what do we do if our post office is already too big or if it keeps on growing in spite of what we've implemented in the previous sections? Well, you can ask or even force your users to start using the GroupWise archives. And although that might indeed take some pressure off your post offices, this might also give you some other headaches:

  • Messages and attachments that are sent to multiple users on your post office and are stored only once (single instance); however, if you use the GroupWise archive to store them in another storage location, each item will be stored separately for every user. These items are thus stored multiple times, which potentially leads to unacceptably high storage needs.

  • Messages stored in GroupWise archives are not always (easily) accessible to the user and certainly not to others. It might be difficult to stay compliant with rules and regulations if you need to provide fast and immediate access to all items, as required by, for example, HIPAA and Sarbanes-Oxley.

  • You will need the GroupWise client to read the messages, and the mailbox account will need to exist in your system to get access to the GroupWise archive. There are some tricks to circumvent this, but all in all it's difficult if not impossible to access an archive without the proper software and the account in your GroupWise environment.

These are just a few examples of why it might be a good idea to take a closer look at a more permanent and flexible solution. And the good news is this: There are several third parties that offer such a solution. These solutions will all be able to either copy or export all messages out of your message store to an alternative format like XML or to a database. And they will make sure that these messages are stored only once, even if that message was sent to multiple users on the same post office. Furthermore, these solutions will offer external viewers that will give rapid access to either the XML store or to the database. Very detailed descriptions of all these solutions are outside the scope of this book, but take a look at these third parties (in alphabetical order):

  • IntelliReach offers MessageArchive, which creates a single-instance storage database to store all messages. MessageArchive collects email over a standard IMAP/SSL interface utilizing the IMAP API available in GroupWise. It includes features like Smart Indexing, capturing a "smart" index of dates, email addresses, select keywords, and proper nouns in a natural language processing engine. After an initial matter search is performed, a detailed, full-text index is created for subsequent legal and regulatory inquiries. You can find more information at www.intellireach.com.

  • Messaging Architects offers GWArchive, which enhances the existing GroupWise archive with several useful features, but also allows you to publish or export GroupWise information into special XML archives or databases. The very powerful yet intuitive XML viewer has several very interesting features to access these XML archives and to investigate these archives in much detail. The GWArchive server has direct access to the GroupWise message store based on the trusted API and can handle all publishing and export tasks automatically. You can find more information at www.messagingarchitects.com.

  • Nexic offers Discovery, a powerful solution to export and publish GroupWise data, giving access to all information stored in GroupWise. The Discovery process will be able to export the GroupWise information automatically in almost any desired format, from a simple ASCII text file to very elaborate XML formats and many database types as well. Additional tools complement this solution and will give rapid access to all the stored information, either onsite or elsewhere, stored for example on a DVD including the viewer. You can find more information at www.nexic.com.

The good news is that GroupWise is very extensible, and especially this latest GroupWise 7 version has several new features that are important for the developers of these types of solutions. And more and more GroupWise environments are implementing these solutions to be compliant with rules and regulations, such as HIPAA and Sarbanes-Oxley.


Summary

Using GroupWise is so much fun that your end users will certainly want to store as much in GroupWise as possible, or they simply don't want to take the time to clean up. Either way, your GroupWise Post Office will keep on growing unless you implement some variant of the solutions that we've described in this chapter.


Chapter 34. Creating a GroupWise-to-GroupWise Communication Solution Across the Internet

Wouldn't it be great if everybody used GroupWise all over the world? Well, it won't happen, of course, but it would certainly solve a lot of problems when communicating with other organizations around the world. Our common denominator is currently SMTP, developed during the early days of the Internet to enable a few thousand people at universities and government agencies to communicate via the still-friendly Internet. Oh boy, have we seen some changes there! Nowadays the Internet is used by billions of people, but the threats and challenges have also developed immensely. For example, the estimates are that approximately 50% of the total email volume can be tagged as spam, unwanted or unnecessary email. And the number of virus attacks is also incredible.

We've learned to live with these challenges, but many of these problems arise from the fact that SMTP has never been designed with these challenges in mind. And although the Enhanced SMTP (ESMTP) tries to plug a few holes, this still isn't good enough. For example, by default, messages sent by either protocol are still in plain readable ASCII. We can, of course, use Secure Messaging with S/Mime to solve this problem, as described in Chapter 30, "Creating a Securing Messaging Solution," but there are other ways as well. You can let your GroupWise system talk to other GroupWise systems directly and natively with much more security and other features by using GroupWise GWMTP communication between your MTA and an MTA at the other side. No need to use the GWIA, just GroupWise-to-GroupWise and automatically!

This chapter explains how to set up and configure GWMTP communication across the Internet, but before you can start using this you need to make sure you understand the concept of GroupWise Internet addressing, as discussed in Chapter 16, "Internet Addressing." By default, when you install GroupWise, Internet addressing is not enabled, but you need to enable it before you can use GWMTP MTA-to-MTA communication. So make sure you've implemented Internet addressing as explained in Chapter 16 before you implement GWMTP.


An Overview of Message Transfer Protocol and Internet Addressing

GroupWise was designed and engineered before the Internet was widely in use for sending SMTP messages via email. As a result, GroupWise uses a proprietary addressing scheme that is made up of the domain, post office, and user ID in a GroupWise system. Because of this, if you were to create a new GroupWise system, and then install the GroupWise Internet Agent (GWIA) to send SMTP messages via the Internet, your users would not be able to simply type an address in the format of user @ internetdomain.com and expect the GroupWise system to know what to do with this address.

When a GroupWise administrator enables Internet addressing, all GroupWise agentsincluding the GroupWise clientbecome aware of this fact, and are able to resolve Internet-style addresses natively. This gives the administrator a lot of flexibility with regard to the way that GroupWise can address and resolve Internet-style addresses.

GroupWise Internet addressing offers several advantages. This is just an overview of the most relevant advantages for this chapter; more can be found in Chapter 16:

  • GroupWise addresses become Internet addresses: With native Internet addressing, GroupWise addresses no longer need to be converted to Internet addressing formats when GroupWise mail is being sent out to the Internet. Instead of users being known internally to the GroupWise system as Domain.PostOffice.UserID, users will be internally known as userid@Internet domain name.

  • GWIA gains flexibility: With Internet addressing enabled, the GWIA will work very hard to match an Internet address with a GroupWise user for incoming SMTP mail. The gateway will still look for the old-style matches with aliases and foreign IDs, as well as for the Internet domain name formats. The term Internet domain name is specific to GroupWise Internet addressing. The Internet domain name is an extra attribute attached to every address in GroupWise, and it makes GroupWise addresses comply with Internet address formats.

    Note

    Internet domain names are sometimes referred to as IDOMAINs. This term might help avoid confusion.

  • You can have direct MTA-to-MTA connectivity between systems: With Internet addressing enabled, you can allow any message transfer agent (MTA) on your system to connect directly to another GroupWise system. The GroupWise message transfer protocol (GWMTP) allows GroupWise users to transparently communicate over the Internet with other GroupWise users in other systems.

    Sending messages via GWMTP effectively eliminates the need to convert messages bound to other GroupWise systems to SMTP format. No gateway or gateway conversions are needed for the two systems to communicate. Leaving the messages in their native format also allows for native GroupWise encryption, compression, and message formats to be retained. Keeping the native message type allows appointments to be sent to users in other GroupWise systems as appointments. These items will show up correctly on calendars, they can be accepted or rejected, and full status tracking is available. The native format also allows for busy searches across the Internet to other GroupWise systems.


Checking Whether Internet Addressing Is Enabled

Enabling Internet addressing is covered in more detail in Chapter 16. For this chapter we just need to check whether it is indeed enabled. Following are the steps for checking whether native Internet addressing is indeed enabled:

1.
Choose Tools, GroupWise System Operations, Internet Addressing. The window shown in Figure 34.1 appears.

Figure 34.1. The Internet Addressing dialog box showing the defined Internet domains for this system. Because at least one Internet domain is created, and a default GWIA is selected, native Internet addressing is indeed enabled

Because at least one Internet domain is created and a default GWIA is selected, you know that native Internet addressing is enabled. In this same window you can check to see what the default Internet addressing format is. Most organizations find that userid@Internet domain name works best, as discussed in more detail in Chapter 16.

2.
Close the Internet Addressing dialog by clicking OK.

Now that we've checked that Internet addressing is indeed enabled, we're ready to make GWMTP communication work.


Enabling MTA-Direct Connectivity (GWMTP)

With Internet addressing enabled, MTAs can now connect directly to other GroupWise systems. This type of connectivity, often called GWMTP for GroupWise message transfer protocol, allows native message format and encryption to be maintained.

Retaining the GroupWise message format between GroupWise systems is not a new concept. The same functionality is available without GWMTP, but it requires a pass-through GWIA or Async gateway. To get the same functionality with these gateways, an external domain and post office would have to be configured and maintained for every other system to which your users will send email. The maintenance of these external user entries and external domains could require a lot of an administrator's time.

The big advantage of GWMTP is that the setup has to be done only once. After it has been enabled, ongoing maintenance should be minimal. The three basic requirements to enable GWMTP are the following:

  • Both systems must enable Internet addressing.

  • Both systems must configure MTAs to use GWMTP.

  • Both systems must publish GWMTP records to the Internet via a domain nameservice (DNS).

This chapter has already discussed enabling Internet addressing. This next section moves directly to a walkthrough of configuring the MTA.

Allowing MTAs to Send Directly to Other GroupWise Systems

The first thing you need to do is allow MTAs to send directly to other GroupWise systems.

Following are the steps to enable an MTA in your GroupWise system to communicate on the Internet with other GroupWise MTAs:

1.
Choose Tools, System Operations, System Preferences, Routing Options to get the window shown in Figure 34.2.

Figure 34.2. The System Preferences Routing Options window is used to define which MTA will receive messages that should be sent on the Internet

2.
Make sure that a default routing domain is specified.

This is the domain that will be able to talk directly to other MTAs over the Internet. You do not want to check the option to force all messages to this domain. Doing so can potentially slow down messaging throughout your entire system.

3.
Check the box labeled MTAs Send Directly to Other GroupWise Systems.

4.
Close the Preferences window.

You have told the entire GroupWise system that if users send a message to an Internet domain that is not in your GroupWise system, the message should first be sent to the default routing domain. If the MTA for the default routing domain determines that the destination domain does not support GroupWise MTP communication over the Internet, it should route the message to the GWIA.

Allowing MTAs to Browse DNS

Now every MTA in your system is going to attempt to look up other GroupWise systems via DNS. This means that every MTA must be able to see a valid domain name server. Typically, DNS requests are transmitted on port 53, so you should make sure that this port is not being filtered by your firewall. Most organizations won't have a problem with this, assuming that they allow end users to browse the Web. Web browsing also requires DNS requests, so port 53 is probably already open.

Allowing MTAs to Connect on High-Numbered Ports

You might, however, have a problem with high-numbered ports. When the MTA finds another system's MTA on the Internet (via DNS), it will try to open a connection there, and its source port will be a high-numbered port.

For security reasons, many administrators do not want to have all MTAs exposed to high-numbered ports on the Internet. If you have this same concern, read about default routing domains and overrides in the next section.

Default Routing Domains and Overrides

The best way to avoid exposing all the MTAs in your system is to tell the GroupWise system to send all mail not destined to a known IDOMAIN to a default route. This would basically be all Internet mail. You rarely will want to force all messages (even messages going to a known IDOMAIN) to the default route. A single system-wide default routing domain is usually advisable only for GroupWise systems that have a low volume of outbound Internet email, however. On large, high-volume systems (more than 50,000 Internet messages per day), the burden on a single MTA can be too great, because all Internet-bound email passes through this MTA. Each outbound message requires a DNS lookup to determine whether it is bound for another GroupWise system.

The solution is to use overrides, as detailed here:

  1. Choose Tools, GroupWise System Operations, System Preferences, Routing Options.

  2. Check the box labeled Force All Messages to Default Routing Domain.

  3. Close the window.

  4. Determine a domain or domains in your system that will be used for routing. These domains will be used as an override default routing domain. In most cases, you will make this decision based on your WAN topology. For instance, all domains in one country should use a routing domain in that country.

  5. Determine a domain or domains that will use the override routing domain instead of the system default specified in system preferences.

  6. Perform steps 7 through 11 for each domain whose routing you want to override.

  7. For domains that will use a default routing domain, browse to the domain's MTA object, right-click it, and select Properties.

  8. Click the Routing Options tab shown in Figure 34.3.

    Figure 34.3. The MTA Routing Options tab enables you to override the default routing domain

    [View full size image]

  9. Click the topmost check box in the Override column.

    This will override the default routing domain specified at the system level.

  10. In the field labeled Default Routing Domain, browse to the domain you have chosen as an override routing domain. The MTA for the domain you route through should have the ability to send to other systems as explained earlier.

  11. Click OK to close the window and save your changes.

To summarize how default routing domains work, there are basically three options you can set at the system level in this area:

  • Allow MTAs to Send Directly to Other GroupWise Systems: This option enables all MTAs system-wide to be able to perform DNS lookups. So if a user sends mail to user@unknownIdomain.com, the MTA will try to perform a DNS lookup on it. If it can, and it finds the appropriate DNS entries for unknownIdomain.com, it sends the message directly over the Internet to this other MTA. If for any reason it cannot perform a DNS lookup or cannot find any DNS entries for unknownIdomain.com, it simply hands the message off to the domain that owns the default GWIA (unless there are any overrides anywhere, and then it obeys the override).

  • Default Routing Domain: With this option, if the MTA gets a message to a known IDOMAIN, it resolves the domain (doesn't have to perform a DNS lookup) to the GroupWise domain that the user is in, reads the link configuration to see how to talk to this GroupWise domain, and sends the message to it. If it gets a message to user@unknownIdomain.com, it once again tries to perform a DNS lookup. If it fails or cannot do this, it sends the message off to the default routing domain. It does not send all mail to this domain, only Internet mail that is destined for unknown IDOMAINs. The default routing domain gets the message and then tries to resolve it via DNS; if this fails, it goes ahead and sends it to the default GWIA.

  • Force All Messages to Default Routing Domain: Finally, with this option, when an MTA gets any message, whether or not it is destined for a known IDOMAIN, it simply shoves it over to the forced default routing domain.

You can use the override options on any of these settings, which basically allow you to change what any particular domain is going to use that differs from what you set under System Preferences, System Operations, Routing Options.

There are basically two ways we recommend for setting up default routing domains so that you do not need to have all MTAs doing DNS lookups. If the majority of the domains should be performing DNS lookups, follow this approach:

  1. From System Operations, System Preferences, click the check box that allows MTAs to send directly to other GroupWise systems.

  2. Next, define a default routing domain that all Internet mail will go to if a DNS lookup fails or if the MTA gets mail that is destined for unknown IDOMAINs.

    Do not check the option to force all messages through the default routing domain.

  3. Go to the properties page of the MTA objects in the domains in which you do not want to perform DNS lookups and select Routing Options from the drop-down list.

  4. From here, click the last check box in the Override column (Allow MTA to Send Directly to Other GroupWise Systems), and then uncheck the option to perform this operation that this MTA inherited from the system level.

    Voila! This MTA is not allowed to perform DNS lookups. This works great if most of your MTAs will perform DNS lookups because you only have to do the override on the MTAs that you do not want to perform the DNS lookups.

If most of your domains should not perform DNS lookups, you take the reverse approach, as outlined in the next series of steps:

1. | From System Operations, System Preferences, do not check the box to allow MTAs to send directly to other GroupWise systems.
2. | Define a default routing domain that all Internet mail will go to if a DNS lookup fails. Otherwise, the MTA is not allowed to perform DNS lookups and it gets mail destined for unknown IDOMAINs. Once again, do not check the option to force all messages through the default routing domain.
3. | Go to the properties page of the MTA objects in the domains in which you do want to perform DNS Lookups. (Obviously, you need to make sure that you do this on the default routing domain defined in step 2.)
4. | Select Routing Options from the drop-down list. Click the last check box in the Override column (Allow MTA to Send Directly to Other GroupWise Systems), and then check the option next to it to actually turn this feature on.

The MTA can now perform DNS lookups. If it cannot find the DNS entry, it sends the message to the default routing domain.

Now a tip on how to determine what each MTA is really doing: The top of an MTA's log file contains the configuration information. Following is an example of the general settings at the beginning of the MTA log:

23:26:20 574  General Settings:
23:26:20 574  Domain Directory:             d:\do3
23:26:20 574  Work Directory:              d:\do3\mslocal
23:26:20 574  Preferred GWIA:              Do1.GWIA7
23:26:20 574  Default Route:               Do3
23:26:20 574  Known IDomains:              *wwwidgets.com
23:26:20 574  Known IDomains:              *taykratzer.com
23:26:20 574  Allow Direct Send to Other Systems:    No
23:26:20 574  Force Route:                No
23:26:20 574  Error Mail to Administrator:       No
23:26:20 574  Display the active log window initially: Yes
23:26:20 574  NDS Authenticated:             Yes [Public]
23:26:20 574  NDS User Synchronization:         Yes
23:26:20 574  Admin Task Processing:           Yes
23:26:20 574  Database Recovery:             Yes
23:26:20 574  Simple Network Management Protocol
(SNMP): Enabled (index 1)

What you are looking for are the Default Route, Known IDomains, Allow Direct Send to Other Systems, and Force Route values. These will tell you exactly how this particular MTA will act.

Remember to think of this entire process from the perspective of the MTA when it receives a message in Internet addressing format. It will first determine whether the IDOMAIN is a known IDOMAIN. If it is, and the Force Route value is No, it will perform a lookup in its index to determine which GroupWise domain the user is in, because it should know about the user, and then look at its link configuration to determine how to route the message to the internal user.

If the message is destined for a user in an unknown IDOMAIN, the MTA will once again check the Force Route value. If the value is set to No, the MTA checks to see whether it can perform a DNS lookup. If it can, it tries to do so. If it finds a match, the MTA tries to connect to the destination MTA across the Internet. If no match is found, it checks the Default Route value, and if something is defined here, the MTA sends the message to this domain. If nothing is defined here, the MTA simply routes the message to the default GWIA.

Publish GWMTP Records to the Internet

Now your MTAs can route messages to other GroupWise systems on the Internet. This is half of the picture. The other half is allowing your MTAs to receive messages from other GroupWise systems. For this to happen, other systems must be able to find at least one of your MTAs using DNS.

GWMTP.TCP Record Information for the DNS Administrator

The following information will be useful to your DNS administrator when defining your GroupWise MTA as an entity that can be contacted on the Internet to transmit GroupWise messages to.

To resolve a foreign Internet domain name, a GWMTP-enabled MTA will perform a DNS lookup for an address record of a particular Internet domain name. If the address record is found, the MTA will look for either a service (SRV) or text (TXT) record for the GWMTP.TCP service.

A full explanation of domain name server configuration is beyond the scope of this text. What this book will try to do is provide you with enough information that you can explain to your DNS administrator which records you need.

Each GWMTP.TCP record will have several values associated with it:

  • Name: The service name must begin with GWMTP.TCP, for instance, GWMTP.TCP.NOVELL.COM.

  • Class: The record class can be SRV or TXT. Choose whichever of these is easiest for you to support using the DNS tools you have.

  • Priority: This can be any number, but for a single-MTA system, it should be 0. If you have more than one MTA, you can set one to be 0, and another to be 1. In this case, the MTA with a priority of 1 will be used only if the MTA with a 0 priority is not responding.

  • Weight: Weight can also be any number. This value is used for load balancing. If two MTAs have the same priority but different weights, the one with the lower weight is preferred. If that MTA is too busy, connections will be made to the MTA with the higher weight (and the same priority) next.

  • Time to live: Typically listed in seconds, this is the amount of time this record will be valid before being refreshed. If you need to make a change to an MTA's IP address or port, the time to live can be the minimum amount of time it will take your changes to propagate across the Internet DNS system.

  • IP address: This is the IP address of the MTA.

  • Port: This is the GWMTP port for this MTA, typically 7100. If you choose another port value here, you must also choose that value under the Network Address tab of the MTA object properties.

Now your DNS has an entry for your MTA that allows other MTAs on the Internet to discover your MTA's capability to speak GWMTP.

In most cases your system defaults will probably work all right, but in some cases you might like to use an override option to make sure that messages are routed to the most efficient route for this location. This type of override can be found in MTA objects. MTA overrides can be used to do the following:

  • Specify default routing domains on a domain-by-domain basis (rather than at the system level)

  • Force all mail to be routed to the routing domain

  • Specify MTA to allow GWMTP communication

A routing option override can be used to route undeliverable local mail through a different domain that might have GWMTP enabled. Additionally, if a routing domain is defined and an override is selected to force all messages to a default routing domain, the domain's MTA will force all mail that is not deliverable in its local domain to be routed through the default routing domain. The last routing option, which allows MTA to send directly to other GroupWise systems, is used to specify whether the domain MTA is allowed to communicate via GWMTP.

Tip

Here is the difference between a default routing domain and a default GWIA. The default routing domain is for Internet-bound email that can be sent via GWMTP. The default GWIA is for Internet-bound email that cannot be sent via GWMTP. For routing purposes, it would therefore make sense to have the default GWIA reside on the default routing domain.


Mail Routing with GWMTP Enabled

Now that you understand the concepts behind GroupWise GWMTP in conjunction with Internet addressing, this section discusses the flow of email through a GWMTP and Internet addressingenabled GroupWise system.

Outbound Email

Internet addressingaware (or IA-aware) clients (GroupWise 5.5x and newer clients) allow mail with Internet addresses to be routed internally or to Internet users without the use of addressing rules or external domain definitions. Without Internet addressing enabled (and no addressing rules in use), messages sent to users with Internet-style addresses are flagged as undeliverable when mail is sent from the client.

With Internet addressing enabled, the client performs less lookup on recipient addresses. Messages with Internet-style addresses are pushed on by the client to be resolved by the POA, MTA, or GWIA. Note, though, that each component in an Internet addressing-aware GroupWise system is capable of parsing Internet address information to some extent, including the GroupWise client. Each component (client, POA, MTA, and GWIA) will do the best it can to resolve the address from its perspective.

If the POA cannot resolve an address, it pushes the message to the domain MTA. If the message is addressed to an Internet address, and the domain MTA cannot resolve the message to one of its post offices, or internal to the system, it will route the message to the default routing domain for a GWMTP lookup by the MTA there. If the recipient address cannot be resolved with a GWMTP DNS lookup, the message will be routed to the default GWIA for transfer to the Internet.

Inbound Email

When a message arrives at a GroupWise system from the outside world, it does so in one of two ways:

  • Direct MTA-to-MTA transfer via GWMTP

  • SMTP/MIME transfer via the GWIA

Note

Messages can also come in through another GroupWise gateway, but typically those are not going to be outside-world messages. Most other gateways, such as the Exchange gateway or the Lotus Notes gateway, are handing explicitly addressed messages to the GroupWise MTA, so the messages can be treated as internal to the GroupWise system.

When a message comes in via GWMTP, the MTA receiving the message will process the message by sending it to the GroupWise domain within the GroupWise system of which the recipient is a member. The recipient's domain routes the message to the recipient's POA, which delivers the message to the recipient's mailbox.

Messages can of course also be delivered via the GWIA. This message flow is described in more detail in Chapter 16.

Naming Conventions

Naming conventions are important for both GWMTP and native Internet addressing via the GWIA. In Chapter 16 see the section "Naming Conventions" for some recommendations.

System Design

This section offers a few suggestions on effectively setting up GroupWise Internet addressing on your GroupWise system:

  • If direct MTA-to-MTA connectivity is enabled, the GroupWise domain that owns the default GWIA should be the default routing domain. This will simplify firewall administration (only one machine needs to be outside the firewall) and reduce traffic.

  • On large systems that span wide area networks, use default GWIA and default routing domain overrides to ensure that traffic bound to the Internet takes the most efficient route. (This assumes that your system has more than one connection to the Internet.)

  • Ensure that all GWMTP-enabled MTAs can receive packets from their assigned port from the Internet and that they can send packets out to the Internet on high-numbered ports.

These system design suggestions are most relevant in large GroupWise systems (5,000 or more), of which there are many!


Summary

GroupWise GWMTP MTA-to-MTA communication via the Internet can be a very valuable option for your organization. It will add many features that the Simple Mail Transfer Protocol is missing and will allow you to send mail, appointments, and even tasks securely over the Internet. It will even allow you to do busy searches, so check it out and make it work.


Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]


SYMBOL

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

- (dash) 2nd
/ (slash) 2nd
/? switch
POA-related switches 2nd
/Home switch
Post Office Agents, loading
/home switch
message transfer agents, loading
/IPLL-DIAG startup switch
(POAs)
/TCPINBOUND-X switch (MTAs)
/TCPTRUNKWIDTH-X switch
(MTAs)
/TCPWAITCONNECT-X switch (MTAs)
/TCPWAITDATA-X switch (MTAs)
0-7 queue directories 2nd 3rd 4th 5th 6th 7th 8th
32-bit Windows client 2nd 3rd 4th
8209 (Path to file not found)
error code 2nd
82xx error codes
89xx error codes
@ switch
message transfer agents, loading
Post Office Agents, loading
\#209help switch
POA-related switches


A

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

A records
high availability GWIA solutions 2nd
aAccess Control Settings
WebAccess Agent 2nd
About ConsoleOne command (Help menu)
access
agents
proxy access, enabling 2nd 3rd
GWIA access 2nd 3rd 4th
configuring 2nd 3rd 4th
database management settings 2nd
host relay settings 2nd 3rd 4th
test operations 2nd
GWIA mailbox access 2nd 3rd [See also related protocols]
troubleshooting file access 2nd 3rd
wireless
handheld devices 2nd 3rd 4th 5th 6th
phones 2nd 3rd 4th
SSL encryption 2nd 3rd
WebAccess templates 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
Access Control (GWIA) 2nd 3rd 4th
Access Control Database Management properties
WebAccess Agent 2nd
accountants
administrators specified as
accounts, restoring [See deleted users, restoring]
Actions command (POA Options menu)
Active Log Window (MTAs) 2nd
address books [See post office databases]
adding fields 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
exporting 2nd 3rd 4th 5th 6th 7th
external system synchronization 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
field labels, changing
field order, changing
fields, adding
importing 2nd 3rd 4th
LDAP address books
configuring for WebAccess 2nd 3rd
personal
properties, setting 2nd 3rd
remote users 2nd
shared
allowing address book creation
sort order, changing 2nd 3rd 4th
addressing [See Internet addressing]
addressing rules 2nd 3rd 4th 5th
setting
testing
ADM (administration process)
Admin Status command (MTA Options menu) 2nd
Admin Status screen (POA console)
admin thread 2nd
admin-defined fields 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
administering GroupWise
domain databases and 2nd 3rd
eDirectory and 2nd
administration process (ADM)
Administration software
installation
Linux 2nd
NetWare 2nd 3rd
administration system 2nd 3rd 4th
admin thread 2nd
snap-ins
version, determining 2nd 3rd
Administrator
described
ADS directory queue
ADS subdirectory (WPCSOUT) 2nd
Advansys Formativ
Agent Settings
POAs 2nd 3rd 4th
Agents 2nd 3rd [See also specific Agents] [See also GroupWise Monitor Agent, GWIA, MTA, POA, WebAccess Agent]
determining status of
displaying version of 2nd
error 7 2nd 3rd
grpwise script 2nd
gwha.conf file 2nd
initializing 2nd 3rd
installation
library code
Linux conventions
log files 2nd 3rd
reinstalling 2nd
starting
startup files
stopping
uninstalling 2nd
unloading 2nd
agents 2nd 3rd [See also specific agents]
Groupwise Monitor [See GroupWise Monitor Agent]
HTTP access to 2nd
HTTP monitoring
GroupWise Internet Agent 2nd 3rd 4th 5th 6th
MTAs 2nd 3rd 4th 5th
Post Office Agents 2nd 3rd 4th 5th 6th 7th 8th
HTTP monitoring, enabling 2nd 3rd 4th
post office agents
MTA message logging, enabling 2nd
proxy access, enabling 2nd 3rd
SNMP monitoring, enabling 2nd 3rd
SSL encryption 2nd 3rd 4th 5th 6th 7th 8th 9th
aliases
GWIA aliases 2nd
objects as
post office aliases
user aliases 2nd
All C/S Statistics command (POA Configuration Options menu)
alternate GWIA configuration 2nd 3rd
Apache web server
loading 2nd 3rd
unloading
Aplication Connections command (POA Configuration Options menu)
Apple
GroupWise 7 cross-platform client 2nd 3rd 4th
Application/Environment properties (WebAccess Application) 2nd
Application/Environment Settings
NovellSpeller object 2nd
Application/Log Settings
NovellSpeller object
Application/Log Settings properties (WebAccess Application)
Application/Security properties (WebAccess Application) 2nd
Application/Services properties (WebAccess Application) 2nd
Application/Settings properties (WebAccess Application) 2nd 3rd
Application/Templates properties (WebAccess Application) 2nd 3rd
applications
trusted 2nd 3rd
appointments
message flow process 2nd
Archive Agent
(GroupWise Messenger) 2nd
archives
auto-archive operations 2nd
directory, specifying 2nd 3rd 4th
location 2nd
locking with client options
maintenance routines
troubleshooting 2nd 3rd 4th
archiving
messages 2nd 3rd
attach retry intervals
attachment records
attachments
BLOB files, storage as
large-file-attachment policies
size limitation
audio
GroupWise Monitor audio notifications 2nd
auditing upgrades 2nd
AUTH protocol
authentication
eDirectory and
eDirectory authentication
LDAP authentication 2nd 3rd 4th 5th 6th 7th 8th
Bind method
Compare method
configuring 2nd 3rd
eDirectory server tips 2nd 3rd
enabling 2nd 3rd 4th 5th 6th
fault tolerance, creating 2nd 3rd 4th 5th 6th 7th 8th
testing 2nd
troubleshooting 2nd
LDAP servers 2nd 3rd 4th
auto-archive operations 2nd
auto-update algorithm 2nd 3rd 4th 5th 6th 7th
AUTOEXEC.NCF file


B

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

backing up
mailboxes
Backup/Restore Mailbox
backups
guardian database 2nd
purge operations 2nd
restores [See restores]
batch moves [See message-file moves]
best practices
GroupWise directory 2nd
GroupWise Internet agent 2nd
Internet addressing 2nd 3rd 4th
naming conventions 2nd 3rd
system design 2nd
message flow 2nd 3rd
message transfer agents 2nd 3rd 4th
Post Office Agents 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
WebAccess 2nd
binary large objects (BLOB files) 2nd
deferred message BLOBs
document BLOB files 2nd
Bind method (LDAP authentication)
blacklisted SMTP hosts 2nd 3rd 4th 5th 6th 7th
blacklists 2nd 3rd 4th
BLOB files 2nd
deferred message BLOBs
document BLOB files 2nd 3rd
location
BLOCKED.TXT file
browsers
GroupWise Messenger client installation 2nd 3rd 4th 5th
user interfaces, associating 2nd 3rd 4th 5th 6th 7th
WebAccess templates, associating 2nd 3rd 4th 5th 6th 7th
build numbers 2nd 3rd
bump numbers 2nd 3rd 4th 5th


C

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

C022 (Database damage)
error code 2nd
C022 error code 2nd 3rd
C05D (Dependent store does not
exist on disk) error code 2nd 3rd 4th
C067 (Store number is invalid)
error code 2nd 3rd
CA
private keys, creating 2nd 3rd 4th
public keys, creating 2nd 3rd
signing certificates
NICI, installing 2nd
Novell Certificate Console (PKI) snap-ins 2nd
CA (certificate authority) 2nd 3rd
certificate location recommendations 2nd 3rd
self-signed certificates
signing certificates
caching
POA databases 2nd 3rd
caching mode
enabling 2nd 3rd 4th
GWCHECK maintenance 2nd
calendaring
importance to system design
calendars
appointments
message flow process 2nd
certificate authority [See CA (certificate authority)] [See CA]
certificate signing requests
creating for private keys 2nd 3rd 4th 5th
public keys, creating 2nd 3rd 4th
certificates
creating 2nd 3rd 4th
exporting 2nd 3rd 4th 5th 6th
importing 2nd 3rd 4th 5th
Check Redirection Links command (POA Configuration Options menu)
CHK subdirectory (WPCSOUT) 2nd
Clear Throughput command (POA Configuration Options menu)
Client Access Settings (post offices)
clients
described 2nd 3rd
GroupWise Messenger
installing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
NVLMSGR.EXE extractor file 2nd 3rd 4th
WebAccess clients 2nd
Windows clients 2nd
Wireless clients 2nd
COMINT.CFG file
command-line switches [See switches]
commands [See names of specific commands]
MTA commands
undocumented 2nd 3rd
POA commands
undocumented 2nd
COMMGR.CFG file 2nd 3rd 4th 5th 6th 7th 8th
Compare method (LDAP authentication)
compression
document BLOB files 2nd
concealing
message subjects
CONFIG utility
configuration [See properties]
Agents
gwha.conf file 2nd
alternate GWIA configuration 2nd 3rd
GWIA configuration files 2nd 3rd
NovellSpeller object
Application/Environment Settings 2nd
Application/Log Settings
POAs
Agent Settings 2nd 3rd 4th
Log Settings properties 2nd 3rd
Maintenance properties 2nd 3rd 4th
Network Address 2nd 3rd 4th
QuickFinder Indexing properties 2nd
Scheduled Events properties 2nd 3rd
post offices
Client Access Settings
Default WebAccess properties
Post Office Settings 2nd
Security properties 2nd
SETUPIP Host web server
NetWare 6.5 2nd 3rd 4th 5th
SLES9 Server 2nd 3rd 4th 5th 6th
WebAccess Agent
Access Control Database Management properties 2nd
Access Control Settings 2nd
Gateway Administrators properties
Gateway Settings properties
Identification properties 2nd
Network Address properties 2nd
Post Office Links Settings 2nd 3rd
Reattach Settings properties 2nd
WebAccess Settings properties 2nd 3rd 4th
WebPublisher Settings 2nd
WebAccess Application
Application/Environment properties 2nd
Application/Log Settings properties
Application/Security properties 2nd
Application/Services properties 2nd
Application/Settings properties 2nd 3rd
Application/Templates properties 2nd 3rd
configuration files
GroupWise Internet Agent
GroupWise Messenger 2nd
Configuration Options menu
(POA console) 2nd 3rd 4th
Configuration Status tool (MTAs) 2nd 3rd
configuring
(***delete section***)
external system synchronization 2nd 3rd
LDAP authentication
WebAccess
default Agents
Provider Agent failover lists, configuring 2nd
WebAccess templates 2nd 3rd 4th 5th 6th 7th
connections [See links]
changing 2nd
foreign domain connections 2nd
GWIA connections
live remote, configuring 2nd 3rd 4th
MTA-level connections
status tracking 2nd 3rd 4th
MTA-level connectivity 2nd 3rd
multi-system connectivity, testing 2nd 3rd
TCP/IP, troubleshooting 2nd 3rd 4th
troubleshooting domain connections 2nd 3rd
console screens
GroupWise Internet Agent 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
john add entries
WebAccess Agent 2nd 3rd 4th
ConsoleOne
connections, changing 2nd
GroupWise client options 2nd 3rd
GroupWise view
accessing
creating objects from 2nd
filtering objects 2nd
GWIA, configuring
access control 2nd 3rd 4th 5th 6th 7th 8th
administrator settings 2nd
alias settings 2nd
identification properties 2nd 3rd 4th 5th
IMAP4 settings 2nd 3rd 4th 5th 6th 7th 8th
LDAP settings 2nd 3rd 4th 5th
log settings 2nd
network address properties 2nd
optional gateway settings 2nd 3rd
POP3 settings 2nd 3rd 4th 5th 6th 7th 8th 9th
post office links
reattach settings 2nd
SMTP/MIME address-handling 2nd 3rd 4th
SMTP/MIME dial-up Internet access 2nd 3rd
SMTP/MIME global settings 2nd 3rd 4th
SMTP/MIME junk mail settings 2nd 3rd
SMTP/MIME message-formatting 2nd 3rd 4th 5th 6th
SMTP/MIME scheduling settings
SMTP/MIME security 2nd 3rd
SMTP/MIME server directories 2nd
SMTP/MIME service extensions 2nd 3rd 4th
SMTP/MIME timeouts
SMTP/MIME undeliverables 2nd 3rd 4th
SSL settings
time settings 2nd 3rd
installing
MTAs, configuring
agent setting properties 2nd 3rd 4th
identification properties
log properties 2nd 3rd
message logging 2nd 3rd
network address properties 2nd 3rd 4th 5th
routing options
scheduled events 2nd 3rd 4th 5th 6th
POAs, configuring 2nd
agent setting properties 2nd 3rd 4th 5th 6th 7th 8th 9th
Agent Settings properties 2nd 3rd 4th
identification properties 2nd
log properties 2nd 3rd 4th
Log Settings properties 2nd 3rd
Maintenance properties 2nd 3rd 4th
maintenance properties 2nd 3rd 4th 5th 6th 7th 8th 9th
Network Address properties 2nd 3rd 4th
network address properties 2nd 3rd 4th 5th 6th 7th
QuickFinder Indexing properties 2nd 3rd 4th 5th 6th 7th
scheduled events 2nd 3rd 4th 5th
Scheduled Events properties 2nd 3rd
SSL encryption
version, determining
content maintenance (information store) 2nd
Convert External Entity
to User tool 2nd
Convert User to External
Entity tool 2nd
copying
primary domain databases from secondary domain databases 2nd
CSR Generate utility 2nd 3rd
CSRs (certificate signing requests)
creating for private keys 2nd 3rd 4th 5th
public keys, creating 2nd 3rd 4th
CSS directory
CSS subdirectory (WPCSOUT) 2nd
Cxxx error codes
Cycle Log command (POA Options menu)


D

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

D107 (Record not found) error code 2nd 3rd
dash (-) 2nd
Database damage (C022) error code 2nd
databases
deferred message database 2nd 3rd
domain [See domain databases]
FLAIM databases 2nd 3rd
guardian 2nd
library databases
message [See message databases]
post office databases
as address book
contents of
creating
data provided by
interaction provided by 2nd
password read from 2nd
updates to 2nd
records [See records]
troubleshooting
access problems
content problems 2nd
document-management problems
NWGUARD.DB registration problems 2nd
structurally damaged databases 2nd 3rd
USERxxx.DB file 2nd 3rd
user [See user databases]
default routing domains 2nd 3rd 4th 5th 6th 7th
default WebAccess Agents, configuring
Default WebAccess properties (post offices)
deferred message database
(NGWDFR.DB) 2nd 3rd
Define User Interfaces window 2nd 3rd 4th 5th 6th 7th 8th 9th
delay time
POA databases
delayed message delivery 2nd
deleted users
restoring
exporting mailboxes 2nd 3rd 4th 5th 6th
import/restore or archive method 2nd 3rd 4th 5th 6th
importing mailboxes 2nd 3rd 4th
message store access, obtaining 2nd 3rd 4th
recover and restore method 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
user directory object, importing 2nd 3rd 4th
deleting
post offices
software distribution directories
trash 2nd 3rd
users
from post offices
GroupWise accounts
recovering deleted accounts 2nd
Delivery Status Notification
(DSN protocol) 2nd 3rd
deltas
Dependent store does not exist
on disk (C05D) error code 2nd 3rd 4th
diagnostics [See also troubleshooting]
archive problems 2nd 3rd 4th
error codes 2nd 3rd 4th
82xx
89xx
Cxxx
Dxxx 2nd
Exxx
isolating responsible components 2nd
LAN sniffers 2nd
Linux server/workstation tools 2nd
machine-specific problems 2nd 3rd 4th
TCP/IP 2nd
uninstall/reinstall 2nd
NetWare-based server tools 2nd
object information, viewing 2nd 3rd 4th
online resources 2nd
scientific method approach 2nd 3rd 4th
user-specific problems 2nd 3rd 4th 5th 6th 7th 8th
components 2nd
Windows-based server tools 2nd
digital signatures 2nd 3rd 4th 5th 6th
S/MIME
combining with encryption
opening digitally signed messages 2nd 3rd 4th 5th 6th 7th
processing messages 2nd 3rd 4th 5th
sending digitally signed messages 2nd 3rd 4th 5th
direct links 2nd 3rd
directories 2nd 3rd [See also GroupWise directory] [See also specific directory names]
domain directories
selecting
user access to
domain directory
eDirectory
described 2nd
primary domain context 2nd
post office directories 2nd
post office directory
structure 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
SDD (Software Distribution Directory)
creating 2nd
moving 2nd
selecting during system creation
WebAccess templates 2nd
DIS (dispatch process)
disabling
GroupWise Document Management 2nd
Disassociate GroupWise
Attributes tool 2nd 3rd
disassociating GroupWise attributes 2nd 3rd 4th
Discovery
disk checks
POA disk checks 2nd 3rd 4th 5th 6th 7th 8th
dispatch process (DIS)
Display Object tool 2nd
distributed installation (WebAccess) 2nd
distribution lists
identification settings 2nd
Internet addressing options 2nd
membership options 2nd
moving
tracking status
nicknames
post office associations
resource associations
user associations
DMDD (document properties database) 2nd
DMDL (document logging database) 2nd
DMS (Document Management System)
DMSH.DB file
DNS
high availability GWIA solutions 2nd 3rd 4th
A records 2nd
alternate GWIA configuration 2nd 3rd
MTP, verifying configuration of 2nd
multiple GWIAs for incoming messages 2nd 3rd
multiple GWIAs for outgoing messages 2nd 3rd 4th
MX records 2nd 3rd 4th
PTR records 2nd 3rd 4th
DNS (domain name server)
domain name resolution 2nd
GWMTP.TCP record information 2nd 3rd
DOCS directory 2nd
document BLOB files 2nd 3rd
compression 2nd
word-list files
document indexes 2nd
document logging database (DMDL) 2nd
Document Management
disabling 2nd
document management
importance to system design
Document Management System (DMS)
document properties database (DMDD) 2nd
Document Properties Maintenance tool
document property sheets
customizing
document references 2nd 3rd 4th 5th
Document Viewer Agent 2nd 3rd 4th 5th
Document Viewer Agent (WebAccess)
document-management system
troubleshooting
documentation
domain databases 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
administration role 2nd 3rd
agent information role 2nd
connections, changing 2nd
creating 2nd 3rd 4th
information replication 2nd
maintenance 2nd 3rd
object ownership 2nd
rebuilding 2nd
repairing 2nd 3rd 4th 5th 6th 7th
size changes 2nd
domain databases (WPDOMAIN.DB)
described 2nd
domain directories
object synchronization 2nd 3rd 4th
selecting
user access to
domain directory
Domain Links button
Link Configuration toolbar
domain name records (DRNs)
viewing
domain name resolution 2nd
domain names 2nd 3rd
default domain names, selecting 2nd
overrides 2nd
domains
capabilities of
creating
from GroupWise view 2nd
databases (WPDOMAIN.DB)
described 2nd
default routing domains 2nd 3rd 4th 5th
described 2nd
domain directories
selecting
user access to
domain directory
file ID, determining
GroupWise view 2nd 3rd
IDOMAINs
defining for external domains 2nd 3rd
IDOMAINs (Internet Domains)
merging external domains 2nd 3rd 4th 5th 6th 7th 8th 9th
message flow between 2nd 3rd 4th 5th
moving 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
gateway configuration issues 2nd 3rd
GroupWise snap-ins, disabling/re-enabling 2nd 3rd
post office connectivity
primary domain connectivity 2nd
task list for 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
testing success of
to new organizational unit (OU) 2nd 3rd 4th 5th 6th 7th 8th
MTAs (message transfer agents)
described 2nd
multiple-system administration 2nd
primary domain databases
copying from secondary domain databases 2nd
primary domains
context 2nd
described 2nd
directories, selecting
naming 2nd 3rd 4th
properties 2nd
address book 2nd 3rd
addressing rules
default WebAccess agents 2nd
identification 2nd
Internet addressing 2nd
post office 2nd
rebuilding 2nd
secondary
creating 2nd
secondary domains
described 2nd
releasing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
synchronizing 2nd 3rd
time zones
specifying
DRNs (domain record numbers)
viewing
DSN (Delivery Status
Notification) protocol 2nd 3rd
Dxxx error codes 2nd
Dynmaic Internet Link


E

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

ecryption
combining with digitally signed S/MIME messages
eDirectory
as GroupWise Messenger directory 2nd
authentication
described 2nd
disassociating GroupWise objects 2nd 3rd 4th 5th 6th
grafting GroupWise objects 2nd 3rd 4th
GroupWise administration and 2nd
GroupWise client logins 2nd 3rd 4th 5th
invalid associations 2nd
LDAP authentication 2nd 3rd
primary domain context 2nd
schema
extending 2nd
tree
adding objects to 2nd
trees
selecting during sytem creation 2nd
user synchronization 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
workforce trees
eDiretory
post office placement
Edit menu
Preferences
Show View Title
editing
users 2nd
email
expiration dates 2nd 3rd
importance to system design
mail routing with Internet addressing enabled
inbound email 2nd 3rd 4th 5th 6th 7th 8th 9th
outbound email 2nd
policies 2nd 3rd 4th
routing
inbound email 2nd
naming conventions
outbound email 2nd
spam
client/mailbox-based solutions 2nd 3rd 4th 5th
definition of
GWIA-based solutions 2nd 3rd 4th 5th 6th
hidden costs of 2nd
Novell partner solutions
Email Address Lookup tool 2nd 3rd
enabling
(***delete section***)
HTTP monitoring 2nd 3rd 4th
IMAP
john add pgs or delete
LDAP authentication 2nd 3rd 4th 5th 6th
mailbox size limits 2nd
MTA message logging 2nd
QuickFinder Indexing
SNMP monitoring 2nd
SOAP
encryped messages 2nd
encryption 2nd
information resources 2nd 3rd 4th
S/MIME 2nd
opening digitally signed messages 2nd 3rd 4th 5th 6th 7th
opening encrypted messages 2nd
processing messages 2nd 3rd 4th 5th
requirements 2nd 3rd 4th 5th
sending digitally signed messages 2nd 3rd 4th 5th
sending encrypted messages 2nd 3rd 4th 5th 6th 7th
SSL encryption
post office agent settings
Public Key Infrastructure (PKI) 2nd 3rd
symmetric key method
WebAccess Agent and Application 2nd
encryption (SSL) [See SSL encryption]
Enhanced SMTP [See ESMTP]
environment status, viewing 2nd
error 7 2nd 3rd
error codes 2nd 3rd 4th
8209 (File to path not found) 2nd
82xx errors
89xx errors
C022 2nd 3rd
C022 (Database damage) 2nd
C05D (Dependent
store does not exist on disk) 2nd 3rd
C067 (Store number is invalid) 2nd 3rd
Cxxx errors
D107 (Record not found) 2nd 3rd
Dxxx errors 2nd
Exxx errors
isolating responsible components 2nd 3rd 4th
online resources 2nd
ESMTP (Enhanced SMTP) 2nd 3rd 4th 5th 6th 7th
ESMTP (extended SMTP) 2nd 3rd 4th
etc/init.d/grpwise script 2nd
etc/opt/novell/groupwise/gwha.conf file 2nd
events
scheduled events 2nd
contents maintenance 2nd 3rd
creating 2nd
editing 2nd
events 2nd
structural maintenance 2nd 3rd
timing of 2nd
Evolution 2nd
exiting
GroupWise Internet Agent
message transfer agents 2nd 3rd
expiration dates 2nd 3rd 4th 5th 6th 7th 8th
messages 2nd 3rd
viewing expired accounts 2nd
Expired Records tool 2nd
exporting
address books 2nd 3rd 4th 5th
certificates 2nd 3rd 4th 5th 6th
mailboxes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
address books 2nd
all messages 2nd
archive directory, configuring 2nd
configuring folder structure 2nd
trash items 2nd
the trash 2nd
extended SMTP (ESMTP) 2nd 3rd 4th
extending eDirectory schema 2nd
external domain records 2nd
external entities 2nd 3rd [See also LDAP authentication]
external system synchronization 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
configuring 2nd 3rd
initiating synchronization 2nd 3rd
MTA connectivity 2nd 3rd 4th 5th
system definitions, creating 2nd 3rd 4th 5th
testing system connectivity 2nd 3rd
Exxx error codes


F

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

failover
WebAccess 2nd 3rd 4th 5th
fault tolerance
LDAP 2nd 3rd 4th 5th 6th 7th 8th
FID (file ID)
FIDs (File IDs)
post office FIDs, determining
FIDs (foreign IDs)
GroupWise Internet Agent 2nd
file flow [See message flow]
file ID (FID)
FILEMON utility
files 2nd 3rd 4th [See also specific file names] [See also logs] [See also specific files]
access
troubleshooting 2nd 3rd
BLOB files 2nd
deferred message BLOBs
document BLOB files 2nd
gwschema.sch
filtering
GroupWise view objects 2nd
Find button
Link Configuration toolbar
FLAIM databases 2nd 3rd 4th
folders
importing 2nd
Sent Items
shared
allowing shared folder creation
forcng
message size limits on GWIA 2nd 3rd 4th 5th 6th
foreign domain connections 2nd
foreign operators
administrators specified as
Formativ (Advansys)
FRAMES directory
free-form Internet address format
frequent contacts lists
FRGNAMES.CFG file


G

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Gateway Administrators properties
WebAccess Agent
gateway links
Gateway Settings properties
WebAccess Agent
gateways
GroupWise view 2nd 3rd
GDS [See GroupWise directory]
troubleshooting
editing users 2nd
removing eDirectory attributes
synchronizing users 2nd
General C/S Statistics command (POA Configuration Options menu)
Global Signatures
creating 2nd
global signatures
GlobalCerts SecureMail Gateway
globally unque ID (GUID)
grace logins 2nd
grafting GroupWise objects
Graft Wizard 2nd
with eDirectory 2nd
group items
groups [See distribution lists]
GroupWare
GroupWise
environment status, viewing 2nd
GroupWise Administrator
described
GroupWise client
environment options 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
GWCHECK utility
installing
DMS (Document Management System)
GroupWise Connector for Outlook
installation interface 2nd 3rd 4th 5th 6th
Internet Browser Integration
JAWS
MSI installation 2nd
Novell PDA Connect
Registry settings 2nd
via GroupWise CD 2nd 3rd 4th 5th 6th 7th 8th 9th
via SDD 2nd 3rd
via ZENWorks 2nd
WMS (Windows Messaging System)
junk mail, controlling 2nd 3rd 4th 5th
licensing options 2nd 3rd 4th
login mode, setting 2nd 3rd 4th
login process 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
command-line options 2nd 3rd
DNS lookups 2nd 3rd 4th
eDirectory calls 2nd 3rd 4th 5th
network provider calls 2nd
NGWNAMESERVER redirection 2nd
Registry settings 2nd 3rd 4th
user data 2nd
message viewing options 2nd
performance-related options 2nd 3rd
platforms
32-bit Windows 2nd 3rd 4th
Evolution 2nd
GroupWise Connector for Outlook 2nd 3rd 4th
IMAP4 2nd 3rd
Linux 2nd 3rd 4th
Macintosh 2nd 3rd 4th
POP3 2nd 3rd
WebAccess with full-featured browser support 2nd
WebAccess with simple HTML support 2nd
wireless 2nd 3rd
propagation of client options 2nd
remote clients
MTA support, configuring 2nd 3rd 4th
remote mode message queues 2nd
send options 2nd 3rd 4th
SETUPIP 2nd
SETUPIP Host web server 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
SETUPIP.EXE Client utility 2nd
troubleshooting 2nd
status tracking 2nd 3rd
upgrading
assigning SDD 2nd
auditing upgrades 2nd 3rd
auto-update algorithm 2nd 3rd 4th 5th 6th 7th
defining SDD 2nd
grace logins, adding 2nd
initiating upgrade 2nd
post office upgrades 2nd 3rd 4th
with SETUPIP 2nd 3rd
wildcard addressing
GroupWise clients [See clients]
GroupWise Connector for Outlook 2nd 3rd 4th 5th
GroupWise Diagnostics command (Tools menu)
Display Object 2nd
Information
Record Enumerations 2nd
GroupWise directory
best practices 2nd
described 2nd 3rd 4th
domain databases 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
administration role 2nd 3rd
agent information role 2nd
creating 2nd 3rd 4th
described 2nd
information replication 2nd
maintenance 2nd 3rd
object ownership 2nd
object synchronization 2nd 3rd 4th
rebuilding 2nd
repairing 2nd 3rd 4th 5th 6th 7th
size changes 2nd
eDirectory
described 2nd
grafting GroupWise objects 2nd 3rd 4th
GroupWise administration and 2nd
invalid associations 2nd
primary domain context 2nd
schema, extending 2nd
trees, selecting during system creation 2nd
user synchronization 2nd 3rd 4th
maintenance 2nd 3rd
post office databases 2nd 3rd 4th 5th
as address book
contents of 2nd
data provided by 2nd
described 2nd
password read from 2nd
POA information provided by 2nd
rebuilding 2nd 3rd 4th
recovering 2nd
updates to 2nd
validating 2nd 3rd
troubleshooting 2nd
object replication 2nd 3rd 4th 5th 6th 7th 8th
GroupWise Document Management
disabling 2nd
GroupWise document management
system [See GWDMS]
GroupWise installation
Administration software
installing on Linux 2nd
installing on NetWare 2nd 3rd
ConsoleOne
eDirectory schema, extending 2nd
Software Distribution Directory, creating 2nd
GroupWise Internet Agent [See GWIA]
GroupWise magazine
GroupWise message stores [See message stores]
GroupWise message transfer protocol (GWMTP) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
GWMTP.TCP record information 2nd 3rd
mail routing
inbound email 2nd
naming conventions
outbound email 2nd
GroupWise Messenger 2nd
administration database
administration software
installing 2nd 3rd 4th 5th
agents, starting 2nd 3rd 4th 5th
clients
installing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
NVLMSGR.EXE extractor file 2nd 3rd 4th
configuration files 2nd
described
directory software 2nd
installing 2nd 3rd 4th 5th 6th 7th 8th
server software 2nd
servers 2nd
installing 2nd 3rd 4th 5th
GroupWise Monitor
custom views 2nd
HTTP monitoring
enabling 2nd
GroupWise Monitor Agent 2nd
audio notifications 2nd
command-line switches
custom views 2nd
HTTP monitoring
enabling 2nd
HTTP port, specifying 2nd 3rd
installing 2nd 3rd 4th
link configuration
Link Trace 2nd
link traffic
message tracking
MTA message logging, enabling 2nd
performance testing
proxy acess, enabling 2nd 3rd
remote notifications 2nd 3rd 4th 5th
reports 2nd
SNMP monitoring
enabling 2nd
SNMP services for Windows, installing 2nd
SNMP/MIB values, viewing 2nd
starting
user traffic
visual notifications 2nd 3rd 4th 5th 6th 7th 8th 9th
HTTP interface 2nd 3rd 4th 5th 6th 7th
Windows interface 2nd 3rd 4th 5th 6th 7th 8th
WPDOMAIN.DB file 2nd 3rd
GroupWise Monitor Application 2nd
client interface
installing
Linux platforms 2nd 3rd 4th 5th 6th 7th 8th
prerequisites 2nd
proxy acess, enabling 2nd 3rd
views 2nd
GroupWise post offices [See post offices]
GroupWise System
time zones, editing 2nd 3rd
GroupWise system
addressing rules 2nd 3rd 4th 5th
admin-defined fields 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
calendaring, importance to system design 2nd
ConsoleOne connections, changing 2nd
creating 2nd 3rd
eDirectory trees, selecting 2nd
from GroupWise view 2nd
software distribution directory, selecting
system names 2nd
described 2nd
design principles 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
document
management, importance to system design 2nd
eDirectory user synchronization 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
email, importance to system design 2nd
external system synchronization 2nd 3rd
GroupWise view 2nd 3rd
Internet addressing 2nd [See Internet addressing]
LDAP server authentication 2nd
local area network (LAN) considerations
naming 2nd
pending operations 2nd
planning 2nd 3rd 4th 5th 6th
postmaster, specifying 2nd
preferences, setting 2nd 3rd 4th 5th 6th
restore area management 2nd 3rd
software directory management 2nd 3rd 4th 5th 6th 7th
wide area network (WAN) considerations 2nd
GroupWise System Operations command (Tools menu) 2nd 3rd
GroupWise systems
multiple-system administration 2nd
IDOMAINs, defining for external domains 2nd 3rd
merging systems 2nd 3rd 4th 5th 6th 7th 8th
primary domains 2nd
releasing domains 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
synchronizing systems 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
GroupWise users [See users]
GroupWise Utilities
(Tools menu)
Recover Deleted Account 2nd
Replace Primary with Secondary 2nd 3rd 4th
GroupWise Utilities (Tools
menu)
Client Options 2nd 3rd
GroupWise Utilities (Tools menu)
Sync Primary with Secondary
GroupWise Utilities command
(Tools menu)
Link Configuration Tool
Synchronize 2nd 3rd
System Maintenance 2nd 3rd 4th 5th 6th
GroupWise Utilities command (Tools menu) 2nd
Backup/Restore Mailbox
Client Options 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
Cleanup \#209 Allow Purge of Items Not Backed Up
Cleanup \#209 Perform Maintenance Purges on Caching/Remote
Client Access \#209 Client Licensing 2nd 3rd
Client Access \#209 Client Login Mode 2nd 3rd
File Location \#209 Archive Directory
File Location \#209 Custom Views
General \#209 Allowed Shared Address Book Creation
General \#209 Allowed Shared Folder Creation
General \#209 Check Spelling Before Send
General \#209 Enable Junk Mail Handling
General \#209 Show Messenger Presence
locking archives with 2nd
propagation of client options 2nd
Send options 2nd 3rd 4th
Threshold tab
Views tab 2nd
Document Properties Maintenance
Email Address Lookup 2nd 3rd
Expired Records 2nd
GW/eDirectory Association 2nd 3rd 4th 5th 6th 7th
Link Configuration 2nd 3rd 4th 5th 6th 7th
Mailbox/Library Maintenance 2nd
New System 2nd 3rd
Recover Deleted Account 2nd
Synchronize 2nd
System Maintenance
User Move Status
GroupWise view
accessing
creating objects from 2nd
filtering objects 2nd
GroupWise, history of 2nd
GroupWiseProvider object 2nd 3rd
grpwise script 2nd
guardian database (NGWGUARD.DB) 2nd
troubleshooting 2nd 3rd 4th 5th 6th
GUID (globally unique ID)
GW/eDirectory Association tool 2nd 3rd 4th 5th 6th
GWAC.DB database 2nd 3rd 4th
GWArchive
GWAUTH.CFG file
GWAVA Redline
GWCHECK 2nd
GWCheck
mailbox sizes, determining 2nd 3rd 4th 5th
GWCHECK UTILITY
archive message store maintenance
GWCHECK utility 2nd 3rd 4th 5th 6th 7th 8th
benefits 2nd 3rd 4th
caching/remote mode maintenance 2nd
log files 2nd 3rd
troubleshooting server-based problems 2nd
GWCSRGEN.EXE utility
private keys, creating 2nd 3rd 4th 5th
GWDMS
directory structure 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
GWDVA.DIR file
GWDVA.DVA file
gwha.conf file 2nd
GWIA
(GroupWise Internet Agent)
Access Control 2nd 3rd 4th
access control 2nd 3rd 4th
configuring 2nd 3rd 4th
database management settings 2nd
host relay settings 2nd 3rd 4th
test operations 2nd
alias type 2nd
aliases 2nd
architecture 2nd 3rd 4th
best practices 2nd
configuration files 2nd 3rd 4th 5th
console screen, administration using 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
daemon
exiting
FID (foreign ID) 2nd
forcing message size limits on 2nd 3rd 4th 5th 6th
high availability 2nd 3rd 4th
A records 2nd
alternate GWIA configuration 2nd 3rd
DNS 2nd 3rd 4th
MTP, verifying configuration of 2nd
multiple GWIAs for incoming messages 2nd 3rd
multiple GWIAs for outgoing messages 2nd 3rd 4th
MX records 2nd 3rd 4th
PTR records 2nd 3rd 4th
HTTP monitoring 2nd 3rd 4th 5th 6th
identification properties 2nd 3rd 4th 5th
IMAP4 settings 2nd 3rd 4th 5th 6th 7th 8th
initializing 2nd
installing 2nd 3rd 4th 5th 6th 7th
Internet addressing [See Internet addressing]
LDAP settings 2nd 3rd 4th 5th
loading 2nd
logs
age of
browsing
configuration information 2nd 3rd 4th 5th
disk space, setting
file path
line format 2nd
logging levels 2nd
message-processing entries 2nd 3rd 4th
POP3 connection entries 2nd 3rd 4th
mailbox access 2nd
message statistics 2nd
network address properties 2nd
optional gateway settings 2nd 3rd
polling intervals 2nd 3rd
POP3 settings 2nd 3rd 4th 5th 6th 7th 8th 9th
post office links
postmaster, specifying 2nd
reattach settings 2nd
reinstalling 2nd
restarting
SMTP/MIME settings
address-handling 2nd 3rd 4th
dial-up Internet access 2nd 3rd
global 2nd 3rd 4th
junk mail settings 2nd 3rd
message-formatting 2nd 3rd 4th 5th 6th
scheduling settings
security settings 2nd 3rd
server directories 2nd
service extensions 2nd 3rd 4th
timeouts
undeliverable messages 2nd 3rd 4th
time settings 2nd 3rd
translation function 2nd
transport function 2nd
uninstalling 2nd
unloading
WPDOMAIN.DB-provided information 2nd
GWIA.CFG file 2nd 3rd
GWIA.NCF file
GWIAs
message flow through 2nd 3rd 4th 5th
troubleshooting 2nd 3rd 4th
moving domains associated with 2nd 3rd
SNMP monitoring, enabling 2nd
spam solutions 2nd 3rd 4th 5th 6th 7th 8th 9th
access control 2nd 3rd
blacklists 2nd 3rd 4th
Mailbomb Protection 2nd
SMTP host identity, testing 2nd
GWIAs (GroupWise Internet Agents)
HTTP monitoring, enabling 2nd
GWIP.NLM
GWMBSize
GWMTP (GroupWise message transfer protocol) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
GWMTP.TCP record information 2nd 3rd
mail routing
inbound email 2nd
naming conventions
outbound email 2nd
GWMTP.TCP record information 2nd 3rd
gwschema.sch file


H

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

handheld device markup
language (HDML)
HDML (handheld device markup
language)
HDML directory
help
links
Help button
Link Configuration toolbar
Help menu
About ConsoleOne command
high availability GWIA solutions 2nd 3rd 4th
A records 2nd
alternate GWIA configuration 2nd 3rd
DNS 2nd 3rd 4th
MTP, verifying configuration of 2nd
multiple GWIAs for incoming messages 2nd 3rd
multiple GWIAs for outgoing messages 2nd 3rd 4th
MX records 2nd 3rd 4th
PTR records 2nd 3rd 4th
high-availability installation (WebAccess) 2nd
high-numbered ports
history of GroupWise 2nd
HTTP
accessing through web browsers
agent access 2nd
ports
specifying for GroupWise Monitor Agent 2nd
HTTP monitoring
enabling 2nd 3rd 4th 5th
GroupWise Internet Agent 2nd 3rd 4th 5th 6th
MTAs 2nd 3rd 4th 5th
Post Office Agents 2nd 3rd 4th 5th 6th 7th 8th
troubleshooting message flow
WebAccess Agent 2nd 3rd 4th
WebAccess Application 2nd 3rd 4th 5th 6th 7th
HTTP monitoring, enabling
post office agents
HTTP ports
Post Office Agents 2nd
Hushmail Web mail service
hyphen (-) 2nd


I

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Identification properties
WebAccess Agent 2nd
identification properties
distribution lists 2nd
domains 2nd
GWIA 2nd 3rd 4th 5th
libraries 2nd
message transfer agents
Post Office Agents 2nd
post offices 2nd
resources 2nd 3rd 4th
WebAccess Agent
identity spoofing
GWIA-based options 2nd 3rd
IDOMAINs (Internet Domains)
defining for external domains 2nd 3rd
IM (intant messaging) [See GroupWise Messenger]
IMAP
enabling
IMAP connectivity, enabling
to Post Office Agents 2nd 3rd 4th 5th 6th
to post office agents
IMAP4
enabling 2nd
GWIA settings 2nd 3rd 4th 5th 6th 7th 8th
IMAP4 clients 2nd
Import/Export utility 2nd
importing
address books 2nd
certificates 2nd 3rd 4th 5th
folders 2nd
mailboxes 2nd 3rd 4th 5th 6th 7th 8th 9th
address books 2nd
folders 2nd
trash items 2nd
trash items 2nd
user\#213s directory object 2nd 3rd
users
Import/Export utility 2nd
inbound email
routing 2nd 3rd 4th 5th 6th 7th 8th 9th
inbound links 2nd
incoming messages
multiple GWIAs 2nd 3rd
INDEX subdirectory (OFUSER) 2nd
indexes
document indexes 2nd
mailbox index 2nd
QuickFinder Indexing
enabling
interval options
number of items, changing
scheduling 2nd
indirect links
creating 2nd 3rd
information store
described 2nd
document references 2nd 3rd
guardian database 2nd 3rd
maintenance 2nd
content maintenance 2nd 3rd
contents maintenance 2nd 3rd
creating scheduled events 2nd 3rd 4th 5th 6th 7th 8th
editing scheduled events 2nd
events scheduled events 2nd
GWCHECK utility 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
message expiration 2nd 3rd
order of scheduled events 2nd
POA scheduled events 2nd 3rd 4th
structural maintenance 2nd 3rd 4th 5th
timing of scheduled events 2nd
trash deletion 2nd 3rd 4th 5th
message
databases [See message databases]
post office directories
GWDMS structure 2nd 3rd 4th 5th 6th 7th 8th 9th
OFFILES 2nd
OFMSG 2nd
OFUSER 2nd
queues 2nd 3rd 4th 5th 6th
user databases [See user databases]
Information tool
initializing
Agents 2nd 3rd
input queues 2nd 3rd 4th 5th 6th 7th 8th
installation
Agents
installation (GroupWise)
Administration software
installing on Linux 2nd
installing on NetWare 2nd 3rd
ConsoleOne
eDirectory schema, extending 2nd
Software Distribution Directory, creating 2nd
installing
cross-platform client on Apple
cross-platform client on Linux 2nd
GroupWise client
DMS (Document Management System)
grace logins, adding 2nd
GroupWise Connector for Outlook
installation interface 2nd 3rd 4th 5th 6th
Internet Browser Integration
JAWS
MSI installation 2nd
Novell PDA Connect
Registry settings 2nd
via GroupWise CD 2nd 3rd 4th 5th 6th 7th 8th 9th
via SDD 2nd 3rd
via ZENWorks 2nd
WMS (Windows Messaging System)
GroupWise Connector for Outlook 2nd
GroupWise Internet Agent 2nd 3rd 4th 5th 6th 7th
GroupWise Messenger 2nd 3rd 4th 5th 6th 7th 8th
clients 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
GroupWise Monitor Agent 2nd 3rd 4th
GroupWise Monitor Application
Linux platforms 2nd 3rd 4th 5th 6th 7th 8th
prerequisites 2nd
NICI (Novell International
Cryptographic Infrastructure) 2nd
SNMP services for Windows 2nd
WebAccess 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
configuration steps 2nd
distributed installation 2nd
high-availability installation 2nd
WebAccess Agent 2nd 3rd 4th
cluster-enabling option
DNS name 2nd 3rd
domain path
IP address 2nd 3rd
passwords 2nd 3rd
UNC path 2nd
usernames 2nd 3rd
WebAccess Gateway 2nd
WebAccess Application 2nd 3rd 4th
configuration file location
DNS names
eDirectory context 2nd
IP address
unloading Java
WebAccess Gateway
instant messaging [See Messenger] [See GroupWise Messenger]
IntelliReach MessageArchive
IntelliReach MessageInsight
Intenet domain names
Internet addressing 2nd 3rd 4th 5th
address format 2nd 3rd
benefits of 2nd 3rd 4th 5th 6th 7th
best practices 2nd 3rd 4th
naming conventions 2nd 3rd
system design 2nd
checking whether enabled 2nd
enabling
acceptable address formats 2nd
default domain names 2nd
default GWIA 2nd
preferred addressing format 2nd
exceptions
distribution list level 2nd
domain level 2nd
post office level
resource level 2nd
user level 2nd
free-form address format
hazards involved with 2nd 3rd
lookup process 2nd 3rd
mail routing
inbound e-mail 2nd 3rd 4th 5th 6th 7th 8th 9th
inbound email 2nd 3rd 4th
naming conventions
outbound e-mail 2nd
outbound email 2nd
mail routing through
MTA-direct connectivity
MTA-direct connectivity, enabling 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
default routing domains 2nd 3rd 4th 5th
DNS browsing
GWMTP records, publishing to Internet
GWMTP.TCP record information 2nd 3rd
high-numbered port connections
overrides 2nd
Routing Options window 2nd
naming conventions 2nd 3rd 4th 5th 6th
old-style GroupWise addressing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
address resolution 2nd 3rd
inbound message resolution 2nd 3rd
limitations 2nd
reply-to addresses 2nd 3rd 4th
overrides 2nd 3rd 4th 5th
default GWIA overrides 2nd
Internet domain name overrides 2nd
preferred addressing format overrides 2nd 3rd
parsing operations 2nd 3rd
parsing scenarios 2nd 3rd
usernames 2nd
system design considerations 2nd 3rd 4th
Internet Addressing dialog box 2nd
Internet Agent [See GWIA (GroupWise Internet Agent)] [See GWIA]
overrides 2nd
Internet Browser Integration
Internet Domain Name dialog box
Internet domain names 2nd 3rd 4th 5th 6th 7th
overrides 2nd
Internet Domains [See IDOMAINs]
Internet mail tracking
Internet proxy client/server ports
Internet username
Internic 2nd
intruder detection
enabling, post offices
Invalid Associations tool 2nd
ipconfig command
IPCONFIG utility
IPTRACE.NLM
IPX/SPX addresses
message transfer agents
Post Office Agents
isolating responsible components 2nd


J

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Java servlet gateway 2nd
JAWS
junk mail
client/mailbox-based solutions 2nd 3rd 4th 5th
definition of
enabling Junk Mail Handling 2nd
GWIA-based solutions 2nd 3rd 4th 5th 6th 7th 8th
access control 2nd 3rd
blacklists 2nd 3rd 4th
Mailbomb Protection 2nd
SMTP host identity, testing 2nd
hidden costs of 2nd
Novell partner solutions
versus spam 2nd
junk mail, filtering 2nd


K

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

key material object
killing
Tomcat servlet engine


L

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

LAN sniffers 2nd 3rd
language page (WebAccess Application), skipping 2nd
LDAP
authentication 2nd 3rd 4th
GWIA settings 2nd 3rd 4th 5th
SSL encryption
enabling for GroupWise Messenger to LDAP server communication 2nd 3rd 4th 5th 6th 7th
enabling for POA to LDAP server communication 2nd 3rd 4th 5th 6th 7th 8th 9th
LDAP address books
configuring for WebAccess 2nd 3rd
LDAP authentication 2nd 3rd 4th 5th 6th 7th 8th
Bind method
Compare method
configuring 2nd 3rd
eDirectory server tips 2nd 3rd
enabling 2nd 3rd 4th 5th 6th
fault tolerance 2nd 3rd 4th 5th 6th 7th 8th
server pooling 2nd 3rd 4th 5th
testing 2nd
troubleshooting 2nd
LDAPProvider object 2nd
libraries
database
naming conventions
default document
property sheets, customizing
finding
GWDMS directory structure 2nd 3rd 4th 5th 6th 7th 8th 9th
identification properties 2nd
storage area properties 2nd 3rd
library numbers
licensing
clients 2nd 3rd 4th
Link button
Link Configuration toolbar
Link Configuration Tool
overriding links 2nd
scheduling links 2nd 3rd 4th
Link Configuration tool 2nd 3rd 4th 5th 6th 7th
Link Trace tool (GroupWise Monitor) 2nd
links 2nd 3rd
;MTA link configuration 2nd
configuring 2nd 3rd 4th 5th 6th 7th 8th
direct
finding
gateway
GWIA links
help
inbound 2nd
indirect 2nd 3rd 4th
mapped
outbound
overriding 2nd
protocols
scheduling 2nd 3rd 4th
status of, tracking 2nd 3rd 4th
TCP/IP
versus UNC links
tracing MTA links 2nd
transfer pull 2nd 3rd 4th 5th
types 2nd
UNC
links (post office)
defining 2nd
direct links 2nd
TCP/IP links 2nd
Linux
Administration software
installing 2nd
diagnostic tools 2nd
GroupWise 7 cross-platform client 2nd 3rd 4th
live user moves 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
loading
Apache web server 2nd 3rd
GroupWise Internet Agent 2nd
message transfer agents 2nd 3rd 4th 5th
Post Office Agents 2nd 3rd 4th 5th
Tomcat servlet engine
WebAccess Agent 2nd 3rd 4th
WebAccess Application 2nd 3rd 4th 5th
locking archives
log files
Agents 2nd 3rd
GWCHECK logs 2nd 3rd
Log Settings properties
POAs 2nd 3rd
Logging Options command (POA Options menu)
logins
client login mode, setting 2nd 3rd 4th
grace logins 2nd
GroupWise client login process 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
GWC logins
command-line options 2nd 3rd
DNS lookups 2nd 3rd 4th
eDirectory calls 2nd 3rd 4th 5th
john sb GroupWise client logins
network provider calls 2nd
NGWNAMESERVER redirection 2nd
Registry settings 2nd 3rd 4th
user data 2nd
WebAccess client 2nd 3rd 4th 5th 6th
logs
GWIA
configuration information 2nd 3rd 4th 5th
message-processing entries 2nd 3rd 4th
POP3 connection entries 2nd
GWIA logs
age of
browsing
disk space, setting
file path
line format 2nd
logging levels 2nd
POP3 connection entries 2nd
MTA logs
active 2nd
age of
body of 2nd
browsing 2nd 3rd
configuring 2nd 3rd 4th
disk space, setting 2nd
file path
general settings 2nd
location
logging levels
performance settings 2nd
process column 2nd 3rd
TCP/IP settings 2nd
writing to new logs
MTAs
message logging 2nd 3rd
POA logs
administration update entries 2nd 3rd
age of 2nd
browsing 2nd
configuring 2nd 3rd 4th 5th 6th
cycling 2nd
diagnostic logging 2nd
disk space, setting 2nd 3rd
file path 2nd
line format 2nd
logging levels 2nd 3rd
message delivery entries
message-delivery entries
verbose logging 2nd
WebAccess logs 2nd 3rd 4th 5th
browsing 2nd
disk space settings 2nd
file path
logging levels
maximum age
Speller Application settings
WebAccess Agent settings 2nd
WebAccess Application settings 2nd
WebPublisher Application settings
lookup model
WebAccess 2nd 3rd 4th 5th
lookup process
Internet addressing 2nd 3rd
looping
reply rules
lsof command


M

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Macintosh
GroupWise 7 cross-platform client 2nd 3rd 4th
mail routing
GWMTP (GroupWise message transfer protocol)
inbound email 2nd
naming conventions
outbound email 2nd
with Internet addressing enabled
inbound e-mail 2nd 3rd 4th 5th 6th 7th 8th 9th
outbound e-mail 2nd
Mailbomb Protection 2nd
mailbombs
GWIA-based solutions 2nd 3rd
mailbox index 2nd
Mailbox/Library Maintenance 2nd
mailboxes
backing up
cleanup options 2nd
databases assigned to 2nd
disk space management 2nd
exporting 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
address books 2nd
all messages 2nd
archive directory, configuring 2nd
configuring folder structure 2nd
trash items 2nd
finding items 2nd
GWIA access 2nd 3rd [See also related protocols]
IMAP, enabling 2nd
importing 2nd 3rd 4th 5th 6th 7th 8th 9th
address books 2nd
folders 2nd
trash items 2nd
Mailbox/Library Maintenance
message database pointers 2nd
NNTP, enabling 2nd
POP3, enabling 2nd
refresh intervals
restoring 2nd 3rd 4th
client-based restoration 2nd 3rd
POA-based restoration 2nd 3rd 4th
size limits 2nd 3rd
archiving solutions 2nd 3rd
caching mailboxes
determining current mailbox size 2nd 3rd 4th 5th
enabling 2nd
implementing 2nd 3rd 4th 5th
informing users about 2nd 3rd 4th 5th
monitoring 2nd
troubleshooting 2nd 3rd 4th 5th
analyze/fix operations 2nd
isolating master mailbox problems 2nd 3rd 4th
repairing master mailbox problems 2nd 3rd
structural rebuilds 2nd
user synchronization 2nd
maintenance handler threads
Post Office Agents
post office agents
Maintenance properties
POAs 2nd 3rd 4th
mapped links
master mailboxes
repairing 2nd
master record 2nd
max thread usage
POA databases
memberships
distribution list options 2nd
post office options
memory queues
merging GroupWise systems 2nd 3rd 4th 5th 6th 7th 8th
message body record
message databases 2nd 3rd 4th 5th 6th [See also OFMSG directory] [See also MSGn.DB file]
BLOB files 2nd
deferred messages 2nd 3rd 4th
naming convention
pointers to records 2nd
maintaining 2nd 3rd
user database relationship 2nd 3rd 4th
message flow
best practices 2nd 3rd
between domains 2nd 3rd 4th 5th
between post offices 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th
between different domains 2nd 3rd 4th
GWIA 2nd 3rd
message flow between domains 2nd 3rd
personal (posted) calendar item scenario 2nd
sending messages within same post office 2nd
simple message scenario 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
troubleshooting 2nd 3rd 4th 5th 6th
within same domain 2nd
calendar appointments 2nd
group items
message database [See message databases]
personal items
queue directories 2nd 3rd 4th 5th 6th
store files 2nd 3rd 4th
TCP/IP-related problems 2nd 3rd 4th
through GWIA 2nd 3rd 4th 5th
troubleshooting 2nd 3rd 4th
user databases [See user databases]
within same post office 2nd 3rd
X-locked files
message handler threads
Post Office Agents
post office agents
message logging (MTAs) 2nd 3rd
message logging process (MLG)
message properties record 2nd
message security
individual messages 2nd 3rd 4th 5th 6th
message stores
described 2nd
maintenance
archive mailboxes
contents 2nd 3rd
GWCHECK utility 2nd 3rd 4th 5th 6th 7th 8th
QuickFinder Indexing
structural 2nd 3rd 4th
user upkeep
size, limiting
message transfer agents [See MTAs]
message transfer ports
message transfer agents 2nd
Post Office Agents 2nd
post office agents 2nd
message transfer process (MTP)
Message Transfer Status command (POA Options menu)
Message Transfer Status screen (POA console)
message-file moves 2nd 3rd 4th 5th 6th 7th 8th 9th
MessageArchive
MessageInsight
messages [See also email]
addressing rules 2nd 3rd 4th 5th
archiving 2nd 3rd
attachment record
cleanup options 2nd
concealing subject of
deferred 2nd 3rd
delayed delivery 2nd
expiration dates 2nd 3rd 4th 5th 6th 7th 8th
incoming messages
multiple GWIAs 2nd 3rd
Internet mail tracking
master record 2nd
message body record
message properties record 2nd
outgoing messages
multiple GWIAs 2nd 3rd 4th
pending status
policies for 2nd 3rd 4th
relaying, preventing 2nd 3rd 4th
retention policies
routed messages
passwords
saving
as custom view file
security [See secure messaging]
send options 2nd 3rd 4th 5th
size limitations
size limits
enabling 2nd
forcing on GWIA 2nd 3rd 4th 5th 6th
implementing 2nd 3rd 4th 5th
informing users about 2nd 3rd 4th 5th
monitoring
spam [See spam]
tracking 2nd 3rd 4th 5th
undeliverable, GWIA 2nd 3rd 4th
viewing options 2nd
wildcard addressing 2nd 3rd
MessageScreen (IntelliReach)
Messaging Agent
(GroupWise Messenger) 2nd
GroupWise Messenger
LDAP support
Messaging Architects
GWArchive
Messenger [See GroupWise Messenger]
described
Messenger client
logged in users, viewing
MIME
GWIA settings
address-handling 2nd 3rd 4th
dial-up Internet access 2nd 3rd
extended SMTP (ESMTP) 2nd 3rd 4th
global 2nd 3rd 4th
junk mail 2nd 3rd
message-formatting 2nd 3rd 4th 5th 6th
scheduling
security 2nd 3rd
server directories 2nd
timeout
undeliverable messages 2nd 3rd 4th
MIMETYPE.CFG file
MLG (message logging process)
Monitor Agent [See GroupWise Monitor Agent]
Monitor Application [See GroupWise Monitor Application]
MONITOR.NLM
monitoring
mailbox size limits 2nd
message size limits
Post Office Agents
via Web browsers
monitoring GroupWise agents [See GroupWise Monitor Agent]
moving
domains 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
gateway configuration issues 2nd 3rd
GroupWise snap-ins, disabling/re-enabling 2nd 3rd
post office connectivity
primary domain connectivity 2nd
task list for 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
testing success of
to new organizational unit (OU) 2nd 3rd 4th 5th 6th 7th 8th
message transfer agents 2nd
post offices 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
client connectivity 2nd
document storage area considerations 2nd
domain-to-post office connectivity
GroupWise snap-ins, disabling/re-enabling 2nd 3rd
GWIA connectivity 2nd
SDD (Software Distribution Directory) issues 2nd
steps for 2nd 3rd 4th 5th 6th 7th
to new organizational units 2nd 3rd 4th 5th
WebAccess connectivity 2nd
users
assessing move success 2nd 3rd
clock considerations
directory-level moves 2nd 3rd 4th 5th 6th 7th
live moves 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
message store integrity
message-file moves 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
minimum recommended steps 2nd 3rd 4th 5th
missing messages 2nd 3rd
multiple users 2nd
passwords, lost 2nd
pending moves 2nd 3rd 4th
MSGn.DB file 2nd [See also message databases]
MSI
installation 2nd
MTA
unloading
MTA-direct connectivity, enabling
MTAs
(message transfer agents)
Admin Status window 2nd
admin thread sub-process 2nd
attach retry intervals
best practices 2nd 3rd 4th
command-line switches 2nd 3rd
commands
undocumented 2nd 3rd
configuring
admin messages 2nd 3rd 4th
agent settings 2nd 3rd 4th
identification properties
live remote support 2nd 3rd 4th
log options 2nd 3rd
network address properties 2nd 3rd 4th 5th
Options menu 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
routing options
scheduled events options 2nd 3rd 4th 5th 6th
startup files
console commands 2nd
database recovery, automatic
exiting 2nd 3rd
HTTP monitoring 2nd 3rd 4th 5th
HTTP monitoring, enabling 2nd
link configuration 2nd 3rd 4th 5th
indirect links 2nd 3rd
link status, tracking 2nd 3rd 4th
overriding links 2nd
scheduling links 2nd 3rd 4th
TCP/IP versus UNC links
tranfer pull links 2nd 3rd 4th 5th
live remote users
listing
loading 2nd 3rd 4th 5th
logs
active logs 2nd
age of
body of 2nd
browsing 2nd 3rd
configuring 2nd 3rd 4th
disk space, setting 2nd
file path
general settings 2nd
location
logging levels
performance settings 2nd
process column 2nd 3rd
TCP/IP settings 2nd
writing to new logs
message logging 2nd 3rd
enabling 2nd
message transfer ports 2nd
moving 2nd
MTA-direct connectivity, enabling 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
default routing domains 2nd 3rd 4th 5th
DNS browsing
GWMTP records, publishing to Internet
GWMTP.TCP record information 2nd 3rd
high-numbered port connections
overrides 2nd
Routing Options window 2nd
multi-system connectivity 2nd 3rd
overrides 2nd
platform options
responsibilities of
restarting 2nd
scan cycles 2nd
scheduled events
configuring 2nd 3rd 4th 5th 6th
SNMP monitoring, enabling 2nd
switches
undocumented 2nd 3rd
system design 2nd
TCP/IP options
thread priority options 2nd
tracing links 2nd
tuning 2nd
WPDOMAIN.DB-provided information 2nd
MTAs (message transfer agents)
described 2nd
MTP
verifying configuration of 2nd
MTP (message transfer process)
multiple MX records 2nd 3rd 4th
multiple-system administration 2nd
IDOMAINs
defining for external domains 2nd 3rd
merging systems 2nd 3rd 4th 5th 6th 7th 8th
primary domains 2nd
releasing domains 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
synchronizing systems 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
MX records
high availability GWIA solutions 2nd 3rd 4th


N

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

names
domain names
default domain names, selecting 2nd
system names 2nd
usernames
parsing 2nd
naming
GroupWise system 2nd
post offices
primary domains 2nd 3rd 4th
naming conventions
Internet addressing 2nd 3rd 4th
NDS (Novell Directory Services) [See eDirectory]
netstat command
NetWare
Administration software
installing 2nd 3rd
SETUPIP Host web server configuration 2nd 3rd 4th 5th
NetWare Loadable Modules (NLMs) 2nd
NetWare servers
performance considerations 2nd
Network Address properties
POAs 2nd 3rd 4th
WebAccess Agent 2nd
network address properties
GroupWise Internet Agent 2nd
John add entries
New System tool 2nd
john add pgs
Nexic Discovery
NGWDFR.DB (deferred message
database) 2nd 3rd
NGWGUARD.DB (guardian database) 2nd
troubleshooting 2nd 3rd 4th 5th 6th
NICI (Novell International
Cryptographic Infrastructure), installing 2nd
nicknames
distribution list nicknames
resource nicknames
user nicknames 2nd
nightly user upkeep
john add entries 2nd 3rd
Post Office Agents 2nd
post office agents 2nd 3rd
NLMs (NetWare Loadable Modules) 2nd
NMSTART.NCF file 2nd 3rd 4th 5th 6th
NNTP
enabling 2nd
Novell Certificate Console
(PKI) snap-ins 2nd
exporting S/MIME certificates 2nd 3rd 4th 5th
Novell Directory Services (NDS) [See eDirectory]
Novell International
Cyptographic Infrastructure (NICI), installing 2nd
Novell Messenger 2nd 3rd [See also GroupWise Messenger]
Novell PDA Connect
Novell website
NovellSpeller object 2nd 3rd [See also Speller Application]
Application/Environment Settings 2nd
Application/Log Settings
logs
NVLMSGR.EXE extractor file 2nd 3rd 4th


O

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

objects 2nd [See also domains, resources] [See also specific objects (i.e., , distribution lists)]
as aliases
binary large objects (BLOB files) 2nd
deferred message BLOBs
document BLOB files 2nd
creating
from GroupWise view 2nd
disassociating from eDirectory 2nd 3rd 4th 5th 6th
grafting with eDirectory 2nd 3rd 4th
GroupWise view 2nd 3rd
information about, viewing 2nd 3rd 4th 5th
ownership 2nd
replication 2nd 3rd 4th 5th 6th 7th 8th
domain databases and 2nd
synchronization 2nd 3rd 4th
OFDIRECT subdirectory
(OFWORK) 2nd
OFFILES directory 2nd
BLOB files 2nd
OFMSG directory 2nd [See also message databases]
deferred message database 2nd 3rd
OFS subdirectory (WPCSOUT) 2nd
OFUSER directory 2nd 3rd [See also user databases]
INDEX subdirectory 2nd
OFWORK directory 2nd
online documentation
Open button
Link Configuration toolbar
open relay blacklists
OpenPGP Message Format
OpenWave software developer kit
operators
administrators specified as
Options menu
(MTA console) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
(POA console) 2nd 3rd 4th 5th 6th 7th 8th 9th
GroupWise Internet Agent 2nd
organizational units (OUs)
moving domains to 2nd 3rd 4th 5th
moving post offices to 2nd 3rd 4th
OUs (organizational units)
moving domains to 2nd 3rd 4th 5th
moving post offices to 2nd 3rd 4th
outbound email
routing 2nd
outbound links
outgoing messages
multiple GWIAs 2nd 3rd 4th
alternate GWIA configuration 2nd 3rd
MTP, verifying configuration of 2nd
Outlook
GroupWise Connector for Outlook 2nd 3rd 4th 5th
output queues
overrides 2nd 3rd 4th 5th 6th 7th
overrides (Internet addressing)
default GWIA overrides 2nd
domain name overrides 2nd
preferred addressing format overrides 2nd 3rd


P

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

PAOs
;message transfer ports 2nd
parsing operations
Internet addressing 2nd 3rd
parsing scenarios 2nd 3rd
usernames, parsing 2nd
passwords
for routed messages
user options 2nd 3rd
WPHOST.DB password 2nd
patching
software distribution directories 2nd 3rd
Path to file not found (8209)
error code 2nd
pending operations 2nd
pending status
performance testing
GroupWise Monitor Agent
personal address books
personal items
PGP
information resources 2nd 3rd 4th
PGP Corporation
Physical Connections command (POA Configuration Options menu)
ping command
PING utility
PING.NLM
PKI
Novell Certificate Console snap-ins 2nd
PKI (Public Key Infrastructure) 2nd 3rd
POA
nightly user upkeep
POAs
(Post Office Agents)
Admin Status screen
admin thread sub-process 2nd
caching options 2nd 3rd
commands
undocumented 2nd
configuring 2nd
Agent Settings 2nd 3rd 4th
agent settings 2nd 3rd 4th 5th 6th 7th 8th 9th
Configuration Options menu 2nd 3rd 4th
identification properties 2nd
log options 2nd 3rd 4th
Log Settings properties 2nd 3rd
logging options 2nd
maintenance options 2nd 3rd 4th 5th 6th 7th 8th 9th
Maintenance properties 2nd 3rd 4th
Network Address properties 2nd 3rd 4th
network address properties 2nd 3rd 4th 5th 6th 7th 8th
Options menu 2nd 3rd 4th 5th 6th 7th 8th 9th
performance-related options 2nd 3rd
QuickFinder Indexing properties 2nd
QuickFinder properties 2nd 3rd 4th 5th
scheduled events options 2nd 3rd 4th 5th
Scheduled Events properties 2nd 3rd
SSL options 2nd 3rd 4th
startup switches
connection options 2nd 3rd 4th
CPU utilitization 2nd
database recovery options 2nd
delay time
disk check options 2nd 3rd 4th 5th 6th 7th 8th
exiting
HTTP monitoring 2nd 3rd 4th 5th 6th 7th 8th
HTTP monitoring, enabling
HTTP passwords
HTTP ports
HTTP SSL
IMAP connectivity 2nd 3rd
IMAP connectivity, enabling 2nd 3rd
IMAP, enabling
Internet proxy client/server port
Internet proxy client/server ports
loading 2nd 3rd 4th 5th
local intranet client/server port 2nd
logs
administration update entries 2nd 3rd
age of 2nd
browsing 2nd
configuring 2nd 3rd 4th 5th 6th
cycling 2nd
diagnostic logging 2nd
disk space, setting 2nd 3rd
file path 2nd
line format 2nd
logging levels 2nd 3rd
message delivery entries
message-delivery entries
verbose logging 2nd
maintenance handler threads 2nd
max thread usage
message priorities 2nd 3rd
message transfer ports 2nd
Message Transfer Status screen
nightly user upkeep 2nd 3rd 4th
platform options
post office databases
interaction with 2nd
proxy server access 2nd 3rd 4th
remote user address books 2nd
scheduled events 2nd 3rd 4th
configuring 2nd 3rd 4th 5th
SNMP monitoring 2nd
SNMP monitoring, enabling 2nd
SOAP connectivity
SOAP, enabling
switches 2nd 3rd 4th 5th 6th 7th
undocumented 2nd
TCP handler threads 2nd 3rd 4th
TCP/IP options 2nd 3rd 4th 5th 6th 7th 8th
POAs (post office agents)
described 2nd
HTTP monitoring, enabling 2nd
Pocket PC devices
accessing GroupWise mailboxes 2nd 3rd 4th 5th 6th 7th 8th 9th
pointers [See aliases]
to message database records 2nd
policies
email 2nd 3rd 4th
pooling LDAP servers 2nd 3rd 4th 5th
POP3
GWIA settings 2nd 3rd 4th 5th 6th 7th 8th 9th
POP3 (post office protocol 3)
enabling 2nd
POP3 clients 2nd
ports
high-numbered ports
HTTP, specifying for
GroupWise Monitor Agent 2nd
IMAP
Internet proxy client/server ports
numbering scheme
Post Office Agents
SOAP
Post Office Agents
best practices 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
post office agents [See POAs]
post office databases 2nd 3rd 4th 5th
as address book
contents of 2nd
creating
data provided by
maintenance 2nd 3rd
password read from 2nd
POA information provided by 2nd
rebuilding 2nd 3rd 4th
recovering 2nd
repairing 2nd 3rd 4th 5th 6th 7th
updates to 2nd
validating 2nd 3rd
post office databases (WPHOST.DB)
described 2nd
Post Office Links button
Link Configuration toolbar
Post Office Links Settings
WebAccess Agent 2nd 3rd
Post Office Settings property page 2nd
post offices 2nd [See also POAs (post office agents)] [See also message flow]
access mode options 2nd
aliases
context
context, establishing
creating
from GroupWise view 2nd
location for
timing of
databases (WPHOST.DB)
described 2nd
deleting
delivery mode options 2nd
described 2nd
design tips 2nd 3rd 4th 5th
directories 2nd 3rd
GWDMS structure 2nd 3rd 4th 5th 6th 7th 8th 9th
OFFILES 2nd
OFMSG
OFUSER
queues 2nd 3rd 4th 5th 6th
e-mail policies 2nd 3rd 4th
file ID, determining
GroupWise view 2nd 3rd
intruder detection
links
defining 2nd
direct links 2nd
TCP/IP links 2nd
live move, disabling 2nd
location
mailboxes
backing up
Mailbox/Library Maintenance
restoring
message databases [See message databases]
message flow [See message flow]
message flow between
between different domains 2nd 3rd 4th
GWIA 2nd 3rd
message flow between domains 2nd 3rd
personal (posted) calendar item scenario 2nd
sending messages within same post office 2nd
simple message scenario 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
troubleshooting 2nd 3rd
within same domain 2nd
message stores
described 2nd
moving 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
client connectivity 2nd
document storage area considerations 2nd
domain-to-post office connectivity
GroupWise snap-ins, disabling/re-enabling 2nd 3rd
GWIA connectivity 2nd
SDD (Software Distribution Directory) issues 2nd
steps for 2nd 3rd 4th 5th 6th 7th
to new organizational units 2nd 3rd 4th 5th
WebAccess connectivity 2nd
multiple per server 2nd
naming
number of per server 2nd
performance-related options 2nd 3rd 4th
properties
aliases
client access 2nd 3rd 4th
Client Access Settings
default WebAccess agents 2nd
Default WebAccess properties
distribution lists
identification 2nd
Internet addressing
libraries
memberships
Post Office Settings 2nd
post office settings 2nd 3rd 4th
resources
security 2nd
Security properties 2nd
rebuilding 2nd
remote file server settings 2nd
SDDs, assigning 2nd
security settings 2nd
size, limiting 2nd
time zones
editing 2nd 3rd
trusted application exemptions
UNC (Universal Naming Convention) paths
upgrading 2nd 3rd 4th
users
number per 2nd
selecting 2nd
WebAccess Agent connectivity 2nd 3rd 4th 5th 6th
postmaster
specifying for GWIA 2nd
preferences
system preferences, setting 2nd 3rd 4th 5th 6th
user database preferences
Preferences command (Edit menu)
Show View Title
primary domain databases
copying from secondary domain databases 2nd 3rd 4th 5th 6th
synchronizing with secondary domain databases 2nd
primary domains 2nd [See also post offices]
context
specifying 2nd
described 2nd
domain directories
selecting
user access to
external domain records 2nd
multiple-system administration 2nd
naming 2nd 3rd 4th
object synchronization 2nd 3rd 4th
post offices
context, establishing
time zones
specifying
prime user databases 2nd
naming
private keys
PGP 2nd 3rd 4th
S/MIME 2nd 3rd 4th
private keys, SSL encryption 2nd
certificate signing requests 2nd 3rd 4th 5th
creating 2nd 3rd 4th 5th
locations recommended for 2nd 3rd
PROBLEM directory
PROBLEM subdirectory (WPCSOUT) 2nd
properties
clients 2nd
accessing
editing 2nd 3rd
environment options 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
john sb GroupWise client
propagating to user database 2nd 3rd
send options 2nd 3rd 4th
setting 2nd 3rd 4th
distribution lists
identification 2nd
Internet addressing 2nd
memberships 2nd
nicknames
domains 2nd
address books 2nd 3rd
addressing rules
default WebAccess agents 2nd
identification 2nd
Internet addressing 2nd
post offices 2nd
GWIA
access control 2nd 3rd 4th 5th 6th 7th 8th
administrator settings 2nd
alias settings 2nd
identification options 2nd 3rd 4th 5th
IMAP4 settings 2nd 3rd 4th 5th 6th 7th 8th
LDAP settings 2nd 3rd 4th 5th
log settings 2nd
network address properties 2nd
optional gateway settings 2nd 3rd
POP3 settings 2nd 3rd 4th 5th 6th 7th 8th 9th
post office links
reattach settings 2nd
SMTP/MIME address-handling 2nd 3rd 4th
SMTP/MIME dial-up Internet access 2nd 3rd
SMTP/MIME global settings 2nd 3rd 4th
SMTP/MIME junk mail settings 2nd 3rd
SMTP/MIME message-formatting 2nd 3rd 4th 5th 6th
SMTP/MIME scheduling settings
SMTP/MIME security settings 2nd 3rd
SMTP/MIME server directories 2nd
SMTP/MIME service extensions 2nd 3rd 4th
SMTP/MIME timeouts
SMTP/MIME undeliverable messages 2nd 3rd 4th
SSL settings
time settings 2nd 3rd
libraries
identification 2nd
storage areas 2nd 3rd
MTAs
agent properties 2nd 3rd 4th
identification options
log options 2nd 3rd
message logging 2nd 3rd
network address properties 2nd 3rd 4th 5th
routing options
scheduled events options 2nd 3rd 4th 5th 6th
NovellSpeller object
Application/Environment Settings 2nd
Application/Log Settings
POAs
agent properties 2nd 3rd 4th 5th 6th 7th 8th 9th
Agent Settings properties 2nd 3rd 4th
identification options 2nd
log options 2nd 3rd 4th
Log Settings properties 2nd 3rd
maintenance options 2nd 3rd 4th 5th 6th 7th 8th 9th
Maintenance properties 2nd 3rd 4th
Network Address properties 2nd 3rd 4th
network address properties 2nd 3rd 4th 5th 6th 7th 8th
QuickFinder Indexing properties 2nd
QuickFinder options 2nd 3rd 4th 5th
scheduled events options 2nd 3rd 4th 5th
Scheduled Events properties 2nd 3rd
SSL options 2nd 3rd 4th
post offices 2nd
aliases
client access 2nd 3rd 4th
Client Access Settings
default WebAccess agents 2nd
Default WebAccess properties
distribution lists
identification 2nd
Internet addressing
libraries
memberships
Post Office Settings 2nd
post office settings 2nd 3rd 4th
resources
security 2nd
Security properties 2nd
resource object properties 2nd 3rd 4th 5th
resources
distribution lists
identification 2nd 3rd 4th
Internet addressing 2nd
nicknames
users
account properties 2nd 3rd 4th 5th
disassociating GroupWise attributes 2nd 3rd 4th 5th 6th
distribution list properties
gateway aliases 2nd
Internet addressing 2nd
nicknames 2nd
X.400-style addresses 2nd
WebAccess Agent
Access Control Database Management properties 2nd
Access Control Settings 2nd
Gateway Administrators properties
Gateway Settings properties
Identification properties 2nd
Network Address properties 2nd
Post Office Links Settings 2nd 3rd
Reattach Settings properties 2nd
WebAccess Settings properties 2nd 3rd 4th
WebPublisher Settings 2nd
WebAccess Application
Application/Environment properties 2nd
Application/Log Settings properties
Application/Security properties 2nd
Application/Services properties 2nd
Application/Settings properties 2nd 3rd
Application/Templates properties 2nd 3rd
WebAccess templates 2nd 3rd 4th 5th 6th 7th
protocols
link protocols
proxy server access
Post Office Agents 2nd
post office agents 2nd
PTR records
high availability GWIA solutions 2nd 3rd 4th
public keys
PGP 2nd 3rd 4th
S/MIME 2nd 3rd 4th
public keys, SSL
creating 2nd 3rd 4th
public keys, SSL encryption 2nd
publishing
GWMTP records


Q

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

queue directories 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
QuickFinder Indexing
enabling 2nd 3rd
interval options 2nd
number of items, changing
scheduling 2nd 3rd
QuickFinder Indexing properties
POAs 2nd
QuickFinder menu (POA)


R

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

RBLs (realtime blacklists) 2nd 3rd 4th
realtime blacklists (RBLs) 2nd 3rd 4th
Reattach Settings properties
WebAccess Agent 2nd
rebuilding
domain databases 2nd
post office databases 2nd 3rd 4th
top-down rebuilds 2nd
rebuilding user databases 2nd
Record Enumerations tool 2nd
Record not found (D107) error code 2nd 3rd
records
A records
high availability GWIA solutions 2nd
attachment record
external domain records 2nd
master record 2nd
message body record
message properties record 2nd
MX records
high availability GWIA solutions 2nd 3rd 4th
PTR records
high availability GWIA solutions 2nd 3rd 4th
Record not found (D017) error code 2nd 3rd
Recover Deleted Account tool 2nd
Recover Deleted Account utility 2nd 3rd 4th
recovering
deleted user accounts 2nd
post office databases 2nd
Redline
refresh intervals, mailboxes
Registry (Windows)
GroupWise installation and 2nd
GroupWise logins and 2nd 3rd 4th
REGMON utility
reinitialize systems
reinstalling
Agents 2nd
reinstalling components 2nd
releasing
secondary domains 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
domains, grafting 2nd 3rd
post offices, grafting 2nd 3rd
pre-release preparation 2nd 3rd
SDD definitions 2nd
steps for 2nd 3rd 4th
remote clients
MTA support, configuring 2nd 3rd 4th
queue directories 2nd
remote mode
enabling 2nd 3rd 4th
GWCHECK maintenance 2nd
remote notifications (GroupWise Monitor) 2nd 3rd
renames [See moving users]
repairing
domain databases 2nd 3rd 4th 5th 6th 7th
post office databases 2nd 3rd 4th 5th 6th 7th
replication 2nd 3rd 4th 5th 6th 7th 8th
domain databases and 2nd
reply rules, looping
reply-to addresses
old-style GroupWise addressing 2nd 3rd 4th
reports
GroupWise Monitor Agent 2nd
resouces
nicknames
resources
distribution list options
identification settings 2nd 3rd 4th
Internet addressing exceptions 2nd
moving
tracking status
type options 2nd
visibility options
restarting
GroupWise Internet Agent
message transfer agents 2nd
restores
client-based message restoration 2nd 3rd 4th 5th
deleted user accounts 2nd 3rd
exporting mailboxes 2nd 3rd 4th 5th 6th 7th 8th
import/restore or archive method 2nd 3rd 4th 5th 6th
importing mailboxes 2nd 3rd 4th 5th
message store access, obtaining 2nd 3rd 4th
recover and restore method 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
user directory object, importing 2nd 3rd
POA-based message restoration 2nd 3rd 4th 5th 6th
restore areas 2nd 3rd
setting up
restoring
mailboxes
retention management
archiving solutions 2nd 3rd
mailbox size limits 2nd 3rd
caching mailboxes
determining current mailbox size 2nd 3rd 4th 5th
enabling 2nd
implementing 2nd 3rd 4th 5th
informing users about 2nd 3rd 4th 5th
monitoring 2nd
message size limits
enabling 2nd
forcing on GWIA 2nd 3rd 4th 5th 6th
implementing 2nd 3rd 4th 5th
informing users about 2nd 3rd 4th 5th
monitoring
ROOTCERT.DER key file 2nd
ROUTE.CFG file
routed messages
passwords
router process (RTR)
routing
GWMTP (GroupWise message transfer protocol)
inbound email 2nd
naming conventions
outbound email 2nd
preferences, setting
Routing Options window 2nd
RTR (router process)


S

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

S/MIME 2nd
certificates
creating 2nd 3rd 4th
exporting 2nd 3rd 4th 5th 6th
importing 2nd 3rd 4th 5th
digitally signed messages
combining with encryption
opening 2nd 3rd 4th 5th 6th 7th
processing 2nd 3rd 4th 5th
sending 2nd 3rd 4th 5th
encrypted messages
opening 2nd
sending 2nd 3rd 4th 5th 6th 7th
information resources 2nd 3rd 4th
requirements 2nd 3rd 4th 5th
Safe-Mail
Save button
Link Configuration toolbar
saving
messages
as custom view file
SCA (scanner process)
scalability
WebAccess 2nd
scan cycles, MTAs 2nd
scanner process (SCA)
scheduled events 2nd
contents maintenance 2nd 3rd 4th 5th
creating 2nd 3rd 4th 5th 6th 7th 8th
editing 2nd 3rd 4th
events 2nd
GroupWise Internet Agent
MTA events, configuring 2nd 3rd 4th 5th 6th
order of 2nd
POA events, configuring 2nd 3rd 4th 5th
structural maintenance 2nd 3rd 4th
TCP/IP WAN links 2nd 3rd
timing of 2nd
trash deletion 2nd 3rd 4th 5th
viewing 2nd
Scheduled Events properties
POAs 2nd 3rd
scheduling
QuickFinder Indexing
schema (eDirectory)
extending 2nd
scientific method 2nd
scripts
grpwise 2nd
SDD (Software Distribution Directory)
creating 2nd
moving 2nd
selecting during system creation
SDDs
(Software Distribution Directories)
creating 2nd 3rd
deleting
editing
GroupWise client installation via 2nd 3rd
GroupWise client upgrades
assigning SDD 2nd
auto-update algorithm 2nd 3rd 4th 5th
build numbers 2nd 3rd
bump numbers 2nd 3rd 4th 5th
defining SDD 2nd
initiating upgrade 2nd
managing 2nd
moving
updating 2nd 3rd
secondary domains
creating 2nd
described 2nd
object synchronization 2nd 3rd 4th
pre-release preparation 2nd 3rd
releasing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
domains, grafting 2nd 3rd
post offices, grafting 2nd 3rd
SDD definitions 2nd
steps for 2nd 3rd 4th
users, grafting 2nd 3rd 4th 5th 6th
rights, assigning 2nd
secure messaging 2nd 3rd 4th 5th 6th 7th 8th
digital signatures 2nd 3rd
encryped messages 2nd
ESMTP (Enhanced SMTP) 2nd 3rd 4th 5th 6th 7th
GlobalCerts SecureMail Gateway
identity spoofing
information resources 2nd 3rd 4th
maintaining secure environments 2nd
non-SMTP connections 2nd 3rd 4th
S/MIME 2nd
certificates, creating 2nd 3rd 4th
certificates, exporting 2nd 3rd 4th 5th 6th
certificates, importing 2nd 3rd 4th 5th
opening digitally signed messages 2nd 3rd 4th 5th 6th 7th
opening encrypted messages 2nd
processing messages 2nd 3rd 4th 5th
requirements 2nd 3rd 4th 5th
sending digitally signed messages 2nd 3rd 4th 5th
sending encrypted messages 2nd 3rd 4th 5th 6th 7th
StartTLS protocol 2nd 3rd 4th 5th 6th 7th
unencrypted emails
Web-based systems
security
authentication
eDirectory and 2nd
LDAP servers 2nd 3rd 4th
Global Signatures
creating 2nd
global signatures
GroupWise Internet Agent 2nd 3rd
Mailbomb Protection 2nd
mailbomb protection 2nd 3rd
post office properties 2nd
SMTP host identity, testing 2nd
SSL encryption [See SSL encryption]
Security properties (post offices) 2nd
Sent Items folder
server pooling, LDAP 2nd 3rd 4th 5th
servers
Apache web server
loading 2nd 3rd
unloading
GroupWise Messenger 2nd 3rd 4th
installing 2nd 3rd 4th 5th
LDAP
authentication 2nd
NetWare [See NetWare servers]
number of post offices per 2nd
SETUPIP Host web server 2nd
configuring on NetWare 6.5 2nd 3rd 4th 5th
configuring on SLES9 Server 2nd 3rd 4th 5th 6th
service extensions, SMTP 2nd 3rd 4th
SETUP.CFG file 2nd 3rd 4th 5th 6th 7th
(GroupWise Messenger) 2nd 3rd
SETUP.EXE
via GroupWise CD 2nd 3rd 4th 5th 6th 7th 8th 9th
via software distribution directories 2nd 3rd 4th
WebAccess
SETUP.INI file 2nd 3rd 4th 5th 6th 7th
SETUPIP 2nd
SETUPIP Host web server 2nd
configuring on NetWare 6.5 2nd 3rd 4th 5th
configuring on SLES9 Server 2nd 3rd 4th 5th 6th
SETUPIP.EXE Client utility 2nd
troubleshooting 2nd
SETUPIP Host web server 2nd
configuring on NetWare 6.5 2nd 3rd 4th 5th
configuring on SLES9 Server 2nd 3rd 4th 5th 6th
SETUPIP.EXE
upgrading GroupWise clients 2nd 3rd
SETUPIP.EXE Client utility 2nd
SETUPIP.EXE file 2nd
SETUPIP.FIL file 2nd 3rd
SETUPIP.US file 2nd 3rd
shared address books
allowing address book creation
shared folders
allowing shared folder creation
Show Configuration command (POA Configuration Options menu)
Show Redirection Tables command (POA Configuration Options menu)
showing
Tomcat servlet engine
signatures [See digital signatures]
Global Signatures
creating 2nd
global signatures
signing certificates
CSRs (certificate signing requests)
creating for private keys 2nd 3rd
public keys, creating 2nd 3rd
NICI, installing 2nd
Novell Certificate Console (PKI) snap-ins 2nd
SIMPLE directory
simple HTML
WebAccess 2nd 3rd 4th 5th 6th 7th
Simple Network Management Protocol (SNMP)
size limits
mailboxes 2nd 3rd
archiving solutions 2nd 3rd
caching mailboxes
determining current mailbox size 2nd 3rd 4th 5th
enabling 2nd
implementing 2nd 3rd 4th 5th
informing users about 2nd 3rd 4th 5th
monitoring 2nd
messages
enabling 2nd
forcing on GWIA 2nd 3rd 4th 5th 6th
implementing 2nd 3rd 4th 5th
informing users about 2nd 3rd 4th 5th
monitoring
slash (/) 2nd
SLES9 Server
SETUPIP Host web server configuration 2nd 3rd 4th 5th 6th
SMTP [See also ESMTP (Enhanced SMTP)]
blacklisted hosts 2nd 3rd 4th 5th 6th 7th
GWIA settings
address-handling 2nd 3rd 4th
dial-up Internet access 2nd 3rd
ESMTP (extended SMTP) 2nd 3rd 4th
global 2nd 3rd 4th
junk mail 2nd 3rd
message-formatting 2nd 3rd 4th 5th 6th
scheduling
security 2nd 3rd
server directories 2nd
statistics pertaining to 2nd 3rd
timeout
undeliverable messages 2nd 3rd 4th
high availability GWIA solutions 2nd
A records 2nd
alternate GWIA configuration 2nd 3rd
DNS 2nd 3rd 4th
MTP, verifying configuration of 2nd
multiple GWIAs for incoming messages 2nd 3rd
multiple GWIAs for outgoing messages 2nd 3rd 4th
MX records 2nd 3rd 4th
PTR records 2nd 3rd 4th
host identity, testing 2nd
security [See secure messaging]
snap-ins
version, determining 2nd 3rd
SNMP
for Windows, installing 2nd
SNMP (Simple Network Management Protocol)
SNMP monitoring
enabling 2nd
SOAP
enabling
Software Distribution Directory (SDD)
creating 2nd
moving 2nd
selecting during system creation
SPAM
GWIA-based solutions 2nd 3rd
spam
client/mailbox-based solutions 2nd 3rd 4th 5th
definition of
GWIA-based solutions 2nd 3rd 4th 5th 6th 7th
access control 2nd 3rd
blacklists 2nd 3rd 4th
Mailbomb Protection 2nd
SMTP host identity, testing 2nd
hidden costs of 2nd 3rd
Novell partner solutions 2nd
versus junk mail 2nd
spam blacklists
spell-checking
enabling
Speller Application [See also NovellSpeller object]
logs
speller servlet
SSL
GWIA settings
SSL encryption 2nd
agents, configuring 2nd 3rd 4th 5th 6th 7th 8th 9th
enabling for GroupWise Messesnger to LDAP server communication 2nd 3rd 4th 5th 6th 7th
enabling for POA to LDAP communication 2nd 3rd 4th 5th 6th 7th 8th 9th
Novell Certificate Console (PKI) snap-ins 2nd
post office agent settings 2nd 3rd 4th
private keys 2nd
certificate signing requests 2nd 3rd 4th 5th
creating 2nd 3rd 4th 5th
locations recommended for 2nd 3rd
public keys 2nd
creating 2nd 3rd 4th
symmetric key method
starting
Agents
GroupWise Monitor Agent
STARTTLS protocol
StartTLS protocol 2nd 3rd 4th 5th 6th 7th
startup files
STARTUP.NCF file
status
Agents
status tracking 2nd 3rd
MTA connections 2nd 3rd 4th
stopping
Agents
STOPWEB.NCF file
store files [See specific databases]
Store number is invalid
(C067) error code 2nd 3rd
STRTWEB.BAT file 2nd 3rd
STRTWEB.NCF file 2nd
subject of messages, concealing
SUSE Linux servers
performance considerations 2nd
switches
(, command-line)
MTA-related 2nd 3rd 4th 5th 6th
POA-related 2nd 3rd 4th 5th 6th 7th
symmetric keys, SSL encryption
synchronization
described 2nd
eDirectory user synchronization 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
external system 2nd
synchronization 2nd
external systems 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
configuring 2nd 3rd
initiating synchronization 2nd 3rd
MTA connectivity 2nd 3rd 4th 5th
system definitions, creating 2nd 3rd 4th 5th
testing system connectivity 2nd 3rd
from ConsoleOne 2nd
object ownership and 2nd 3rd 4th 5th
troubleshooting
record enumeration
Synchronize tool (GroupWise Utilities) 2nd 3rd
synchronizing
domains 2nd 3rd
users 2nd 3rd 4th
System Maintenance
System Maintenance tool
Recover Database 2nd
Validate Database
System Maintenance tool (GroupWise Utilities)
system, GroupWise [See GroupWise system]


T

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

TCP handler threads
Post Office Agents 2nd
post office agents 2nd
TCP/IP
MTA log settings 2nd
troubleshooting 2nd 3rd 4th 5th 6th 7th 8th 9th
TCP/IP links 2nd 3rd
versus UNC links
TCP/IP options
GroupWise Internet Agent
message transfer agents
Post Office Agents 2nd 3rd 4th 5th 6th
post office agents 2nd
TCPCON.NLM
telnet command
TELNET utility
templates, WebAccess 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
browser detection 2nd
browser user agents, associating 2nd 3rd 4th 5th 6th 7th
configuring 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
defining 2nd
directories 2nd
location
shipped with GroupWise 7 2nd 3rd
simple HTML 2nd 3rd 4th 5th 6th 7th
WML (wireless markup language) 2nd 3rd 4th 5th 6th
testing
GWIA access settings 2nd
LDAP authentication 2nd
multi-system connectivity 2nd 3rd
themes
WebAccess client 2nd 3rd
threads
admin 2nd
threshold values 2nd
tickle queue
time zones
editing 2nd 3rd
specifying
WebAccess Agent 2nd
TLS (Transport Layer Security)
secure messaging 2nd 3rd 4th
Tomcat servlet engine 2nd
killing
loading
showing
unloading
toolbars
Link Configuration
Tools menu
GroupWise Diagnostics
Display Object 2nd
Information
Record Enumerations 2nd
GroupWise System Operations 2nd 3rd
Addressing Rules 2nd 3rd 4th 5th
Admin-Defined Fields 2nd 3rd 4th 5th 6th 7th 8th
eDirectory User Synchronization 2nd 3rd
External System Synchronization 2nd
Global Signatures 2nd
Internet Addressing 2nd
LDAP Servers 2nd
Pending Operations 2nd
Restore Area Management 2nd 3rd
Select Domain 2nd
Software Directory Management 2nd 3rd 4th 5th 6th 7th
System Preferences 2nd 3rd 4th 5th 6th
Time Zones 2nd 3rd
Trusted Applications 2nd 3rd
GroupWise Utilities 2nd
Backup/Restore Mailbox
Client Options 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th
Document Properties Maintenance
Email Address Lookup 2nd 3rd
Expired Records 2nd
GW/eDirectory Association 2nd 3rd 4th 5th 6th 7th
Link Configuration 2nd 3rd 4th 5th 6th 7th
Link Configuration Tool
Mailbox/Library Maintenance 2nd
New System 2nd 3rd
Recover Deleted Account 2nd 3rd 4th
Replace Primary with Secondary 2nd 3rd 4th
Sync Primary with Secondary
Synchronize 2nd 3rd 4th 5th
System Maintenance 2nd 3rd 4th 5th 6th 7th
User Move Status
Utilities
User Move Status 2nd 3rd 4th 5th 6th 7th 8th
top command
top-down rebuilds 2nd
traceroute command
tracert command
tracing
MTA links 2nd
tracking
messages 2nd 3rd 4th
transfer pull links 2nd 3rd 4th 5th
Transport Layer Security (TLS)
secure messaging 2nd 3rd 4th
trash maintenance
creating scheduled events for 2nd 3rd 4th
exporting trash 2nd 3rd 4th
importing trash 2nd 3rd 4th
trash, deleting 2nd 3rd
troubleshooting [See also diagnostics]
archives 2nd 3rd 4th
databases
content problems 2nd
document-management problems
NGWGUARD.DB registration 2nd
structurally damaged databases 2nd 3rd
domain databases 2nd 3rd 4th 5th 6th 7th
error codes 2nd 3rd 4th
82xx
89xx
C022 2nd 3rd
Cxxx
Dxxx 2nd
Exxx
isolating responsible components 2nd
file access 2nd 3rd
GroupWise directory 2nd
editing users 2nd
object replication 2nd 3rd 4th 5th 6th 7th 8th
removing eDirectory attributes
synchronizing users 2nd
GWCHECK, server-based problems 2nd
GWIA 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
LAN sniffers 2nd
LDAP authentication 2nd
Linux server/workstation tools 2nd
machine-specific problems 2nd 3rd 4th
TCP/IP 2nd
uninstall/reinstall 2nd
mailboxes 2nd 3rd 4th 5th
analyze/fix operations 2nd
isolating master mailbox problems 2nd 3rd 4th
repairing master mailbox problems 2nd 3rd
structural rebuilds 2nd
user synchronization 2nd
message flow
best practices 2nd 3rd 4th 5th 6th 7th
between post offices 2nd 3rd
Internet e-mail 2nd 3rd 4th
TCP/IP-related problems 2nd 3rd 4th
X-locked files
NetWare-based server tools 2nd
NGWGUARD.DB 2nd 3rd 4th 5th 6th
observation phase 2nd 3rd
online resources 2nd
post office databases 2nd 3rd 4th 5th 6th
Record not found (D017) error 2nd 3rd
scientific method approach 2nd 3rd 4th
SETUPIP 2nd
synchronization
record enumeration
TCP/IP 2nd 3rd 4th 5th 6th 7th 8th 9th
user-specific problems 2nd 3rd 4th 5th 6th 7th 8th
components 2nd
users
archive problems 2nd 3rd
moving users 2nd 3rd 4th
user-specific problems 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
USERxxx.DB file 2nd 3rd
Windows-based server tools 2nd
trusted applications 2nd 3rd
post office exemptions


U

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

UNC (Universal Naming Convention) paths
UNC links
UNC paths
WebAccess Agent 2nd
undeliverable messages
GWIA 2nd 3rd 4th
Undo button
Link Configuration toolbar
uninstalling
Agents 2nd
uninstalling components 2nd
Universal Naming Convention (UNC) paths
unloading
Agents 2nd
Apache web server
Tomcat servlet engine
updating
software distribution directories 2nd 3rd
upgrading
GroupWise client
with SETUPIP 2nd 3rd
upgrading GroupWise client
auditing upgrades 2nd 3rd
auto-update algorithm 2nd 3rd 4th 5th 6th 7th
grace logins, adding 2nd
initiating upgrade 2nd
post office upgrades 2nd 3rd 4th
SDDs
assigning to post offices 2nd
defining 2nd
user databases 2nd 3rd 4th 5th [See also OFUSER directory] [See also USERxxx.DB file]
analyze/fix operations 2nd
folders
message database relationship 2nd 3rd 4th
personal address books
personal items stored in
pointers 2nd
preferences
prime user databases 2nd
re-creating 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
exporting mailboxes 2nd 3rd 4th 5th 6th 7th 8th 9th
importing mailboxes 2nd 3rd 4th 5th
rebuilds, structural 2nd
record types 2nd 3rd
user interfaces
defining 2nd 3rd 4th 5th 6th
User Move Status tool
User Move Status utility 2nd 3rd 4th 5th 6th 7th 8th
usernames
parsing 2nd
usernames (Internet)
users
account IDs
account properties 2nd 3rd 4th 5th
adding
to post offices
adding to post offices 2nd
aliases 2nd
creating
from GroupWise view 2nd
definition o
deleting
from post offices
GroupWise account
recovering deleted accounts 2nd
described
distribution list properties
eDirectory synchronization 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
editing 2nd
expiration dates
viewing expired accounts 2nd
external entities 2nd 3rd [See also LDAP authentication]
converting to eDirectory users 2nd
converting users to
file ID (FID)
file IDs
gateway access
globally unque ID (GUID)
IDs
finding 2nd 3rd
importing
Import/Export utility 2nd
Internet addressing exceptions 2nd
logins, disabling
moving
assessing move success 2nd 3rd
between post offices
clock considerations
directory-level moves 2nd 3rd 4th 5th 6th 7th
live moves 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
message store integrity
message-file moves 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
minimum recommended steps 2nd 3rd 4th 5th
missing messages 2nd 3rd
multiple users 2nd
passwords, lost 2nd
pending moves 2nd 3rd 4th
nicknames 2nd
password options 2nd 3rd
preferences, setting 2nd
restoring
exporting mailboxes 2nd 3rd 4th 5th 6th
import/restore or archive method 2nd 3rd 4th 5th 6th
importing mailboxes 2nd 3rd 4th
message store access, obtaining 2nd 3rd 4th
recover and restore method 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
user directory object, importing 2nd 3rd 4th
synchronizing 2nd 3rd 4th
tracking messages 2nd 3rd 4th 5th
troubleshooting
archive problems 2nd 3rd
moving users 2nd 3rd 4th
user-specific problems 2nd 3rd 4th 5th 6th 7th 8th
user-specific problems components 2nd
USERxxx.DB file 2nd 3rd
visibility settings 2nd
X.400-style addresses 2nd
USERxxx.DB file 2nd 3rd [See also user databases]
troubleshooting 2nd 3rd
utilities [See GroupWise Utilities command] [See names of specific utilities]
Utilities command (Tools menu)
User Move Status 2nd 3rd 4th 5th 6th 7th 8th


V

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

v (information store)
validating
post office databases 2nd 3rd
View Log Files command (POA Options menu)
View Throughput command (POA Configuration Options menu)


W

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

WAP (wireless access protocol) 2nd 3rd 4th 5th 6th
WAP emulators
Web browsers
.See also HTTP monitoring
GroupWise Messenger client installation 2nd 3rd 4th 5th
monitoring POAs through
user interfaces, associating 2nd 3rd 4th 5th 6th 7th
WebAccess templates, associating 2nd 3rd 4th 5th 6th 7th
web browsers
monitoring POA (Post Office Agent) with 2nd
Web clipping
Web-based secure messaging systems
WEBAC70A.WAA file
WEBACC.CFG file 2nd 3rd 4th 5th
WEBACC.CFG files
WebAccess
full-featured browser support 2nd
logs 2nd 3rd
browsing 2nd
monitoring through Web browser
wireless access
handheld devices 2nd 3rd 4th 5th
phones 2nd 3rd 4th
SSL encryption 2nd
WebAccess Agent 2nd
Access Control Database Management properties 2nd 3rd 4th 5th 6th
Access Control Settings 2nd 3rd 4th 5th 6th
access control settings
administrator roles
best practices 2nd
cluster-enabling
console 2nd 3rd 4th
default Agent, configuring
Document Viewer Agent 2nd 3rd 4th 5th
encryption keys 2nd 3rd 4th 5th 6th
enviroment settings 2nd
fault tolerance 2nd 3rd 4th 5th
failover model 2nd 3rd 4th 5th
lookup model 2nd 3rd 4th 5th
multiple agents and applications servers 2nd 3rd
Gateway Administrators properties
Gateway Settings properties
high-availability installation 2nd
HTTP monitoring 2nd 3rd 4th
Identification properties 2nd 3rd
installing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
configuration steps 2nd
DNS names 2nd 3rd
domain path
IP addresses 2nd 3rd
UNC path 2nd
WebAccess Gateway 2nd
LDAP address books, configuring 2nd 3rd
loading 2nd 3rd 4th
logs 2nd 3rd 4th
disk space settings 2nd
file path
logging levels
maximum age
WebAccess Agent settings 2nd
WebPublisher Application settings
lookup model
multiple agents, configuring 2nd 3rd 4th 5th 6th
Network Address properties 2nd
passwords
platform
post office links 2nd 3rd
Post Office Links Settings 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
Reattach Settings properties 2nd 3rd 4th 5th 6th
relationship with WebAccess Application 2nd 3rd
scalability 2nd
shutting down
startup file
status
timeout values 2nd
usernames
WebAccess Settings properties 2nd 3rd 4th
WebAccess Settings property page 2nd 3rd 4th
WebPublisher configuration 2nd
WebPublisher Settings 2nd
WPDOMAIN.DB-provided information 2nd
WebAccess agent
distributed installation 2nd
WebAccess agents
domain default agent, selecting 2nd
post office default, selecting 2nd
WebAccess Application 2nd 3rd
best practices 2nd
distributed installation 2nd
Document Viewer Agent 2nd 3rd 4th 5th
encryption keys 2nd 3rd 4th 5th
fault tolerance 2nd 3rd 4th 5th
failover model 2nd 3rd 4th 5th
lookup model 2nd 3rd 4th 5th
multiple agents and applications servers 2nd 3rd
GroupWiseProvider object 2nd 3rd
high-availability installation 2nd
HTTP monitoring 2nd 3rd 4th 5th 6th 7th
installing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
configuration file location
DNS names
eDirectory context 2nd
IP address
unloading Java
WebAccess Gateway 2nd
language page, skipping 2nd
LDAP address books, configuring 2nd 3rd
LDAPProvider object 2nd
loading 2nd 3rd 4th 5th
logs 2nd 3rd 4th
disk space settings 2nd
file path
logging levels
maximum age
Speller Application settings
WebAccess Application settings 2nd
multiple agents, configuring 2nd 3rd 4th 5th 6th
NovellSpeller object 2nd
Application/Environment Settings 2nd
Application/Log Settings
platforms
Provider Agent failover lists, configuring 2nd
relationship with WebAccess Agent 2nd 3rd
scalability 2nd
security settings 2nd
services available, defining 2nd
status 2nd
version information
WebAccess object component 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Application/Environment properties 2nd
Application/Log Settings properties
Application/Security properties 2nd
Application/Services properties 2nd
Application/Settings properties 2nd 3rd
Application/Templates properties 2nd 3rd
WebAccess client
logging in to 2nd 3rd
logins 2nd 3rd
themes 2nd 3rd
WebAccess clients 2nd
WebAccess Document Viewer Agent
WebAccess Gateway
installing
WebAccess object (WebAccess Application) 2nd
Application/Environment properties 2nd
Application/Log Settings properties
Application/Security properties 2nd
Application/Services properties 2nd
Application/Settings properties 2nd 3rd
Application/Templates properties 2nd 3rd
WebAccess Settings properties
WebAccess Agent 2nd 3rd 4th
WebAccess templates 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
browser detection 2nd
browser user agents, associating 2nd 3rd 4th 5th 6th 7th
configuring 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
defining 2nd
directories 2nd
location
shipped with GroupWise 7 2nd 3rd
simple HTML 2nd 3rd 4th 5th 6th 7th
WML templates 2nd 3rd 4th 5th 6th
WEBCLIP directory
WebPublisher
WebAccess Agent configuration 2nd
WebPublisher Application 2nd
log settings
WebPublisher Settings
WebAccess Agent 2nd
wildcard addressing 2nd 3rd
Windows
GroupWise 7 32-bit Windows 2nd 3rd 4th
server diagnostics tools 2nd
Windows CE devices
accessing GroupWise mailboxes 2nd 3rd 4th 5th 6th 7th 8th 9th
Windows clients 2nd
Windows Messaging System (WMS)
Windows Registry
GroupWise installation and 2nd
GroupWise logins and 2nd 3rd 4th
wireless access
handheld devices 2nd 3rd 4th 5th 6th
phones 2nd 3rd 4th
SSL encryption 2nd 3rd
WebAccess templates 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
wireless access protocol (WAP) 2nd 3rd 4th 5th 6th
Wireless clients 2nd
wireless platforms 2nd
WML (wireless markup language)
WebAccess templates 2nd 3rd 4th 5th 6th
WML directory
WMS (Windows Messaging System)
word-list files
workforce trees
WPCSIN directory 2nd 3rd 4th
WPCSOUT directory 2nd
WPDOMAIN.DB 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
administration role 2nd 3rd
agent information role 2nd
creating 2nd 3rd 4th
information replication 2nd
maintenance 2nd 3rd
object ownership 2nd
object synchronization 2nd 3rd 4th
rebuilding 2nd
repairing 2nd 3rd 4th 5th 6th 7th
size changes 2nd
WPDOMAIN.DB (domain database)
described 2nd
WPDOMAIN.DB file 2nd 3rd 4th
WPHOST.DB 2nd 3rd 4th 5th
as address book
contents of 2nd
creating
data provided by
maintenance 2nd 3rd
password read from 2nd
POA information provided by 2nd
rebuilding 2nd 3rd 4th
recovering 2nd
repairing 2nd 3rd 4th 5th 6th 7th
updates to 2nd
validating 2nd 3rd
WPHOST.DB (post office database)
described 2nd
WPROF.DB file
WPROF50.DB file 2nd 3rd 4th


X

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

X-locked files
X-spam headers 2nd
X.400-style user addresses 2nd
XE \#210WebAccess Application
Provider Agent failover lists, configuring\#211 XE \#210configuring
WebAccess Provider Agent failover lists, configuring\#211
XSPAM.CFG file


Z

Previous Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

ZENWorks
GroupWise client installation via 2nd